目录
一、Redis性能压测工具 redis-benchmark
二、redis的配置检查
1、检查redis持久化操作
1）RDB
2）AOF
2、检查内存情况
3、检查redis延迟情况
1）Slowlog（慢查询）
2）Latency Monitoring（延时监控）
一、Redis性能压测工具 redis-benchmark
命令
./redis-benchmark -h xxx -p 7001 -c 100 -n 100000
====== SET ======
100000 requests completed in 3.38 seconds //10万个请求需要3.38s
100 parallel clients //100客户端
3 bytes payload //每次写三个字节
keep alive: 1 //只有一台服务器来处理这些请求，单机性能//下面百分比表示处理比例所需要的时间
0.00% <= 1 milliseconds
92.54% <= 2 milliseconds
99.41% <= 3 milliseconds
99.76% <= 4 milliseconds
99.82% <= 5 milliseconds
99.83% <= 6 milliseconds
99.90% <= 7 milliseconds
99.97% <= 8 milliseconds
99.98% <= 9 milliseconds
100.00% <= 10 milliseconds
100.00% <= 10 milliseconds//表示每秒处理29542.10个的请求
29542.10 requests per second
二、redis的配置检查
1、检查redis持久化操作
Redis持久化操作有两种：RDB和AOF
1）RDB
即snap shotting 快照持久化，这个持久化的操作在redis中是默认开启的，一次性把redis中全部的数据保存为一份存储在硬盘中，如果数据非常多的话，就不适合该持久化操作。在redis.conf文本中可以配置频率:
save 900 1:表示900秒内如果超过1个key被修改，则发起快照保存
save 300 10:表示300秒超过10个key被修改，发起快照
save 60 10000：表示60秒超过10000个key被修改，发起快照
保存的文件名和目录如下：
2）AOF
append only file(AOF持久化)，这个持久化操作可以把用户的每个命令都保存到数据中，包括CRUD操作，还原数据的时候就是把这些执行执行而已。首先需要开启AOF持久化操作，同样需要修改redis.conf文件，需要注意的是开启后会清空redis中的数据，因此在安装完redis后就需要开启AOF操作
最后启动后，会在当前目录中看到appendonly.aof文件。AOF的追加频率，同样需要编辑redis.conf文件，来修改AOF的追加频率，常见参数如下：
#appendfsync always:每次收到命令就立即强制写入磁盘，性能最慢，但是保证完全的持久化
#appendfsync everysec:每秒钟强制写入磁盘一次，在性能和持久化方面最了很好的折中
#appendfsync no:完全依赖操作系统，性能好的时候就持久，不好的时候就不持久化
2、检查内存情况
used_memory：由 Redis 分配器分配的内存总量，包含了redis进程内部的开销和数据占用的内存，以字节（byte）为单位
used_memory_human：已更直观的单位展示分配的内存总量。
used_memory_rss：向操作系统申请的内存大小。与 top 、 ps等命令的输出一致。
used_memory_rss_human：已更直观的单位展示向操作系统申请的内存大小。
used_memory_peak：redis的内存消耗峰值(以字节为单位)
used_memory_peak_human：以更直观的格式返回redis的内存消耗峰值
used_memory_peak_perc：使用内存达到峰值内存的百分比，即(used_memory/ used_memory_peak) *100%
used_memory_overhead：Redis为了维护数据集的内部机制所需的内存开销，包括所有客户端输出缓冲区、查询缓冲区、AOF重写缓冲区和主从复制的backlog。
used_memory_startup：Redis服务器启动时消耗的内存
used_memory_dataset：数据占用的内存大小，即used_memory-sed_memory_overhead
used_memory_dataset_perc：数据占用的内存大小的百分比，100%*(used_memory_dataset/(used_memory-used_memory_startup))
total_system_memory：整个系统内存
total_system_memory_human：以更直观的格式显示整个系统内存
used_memory_lua：Lua脚本存储占用的内存
used_memory_lua_human：以更直观的格式显示Lua脚本存储占用的内存
maxmemory：Redis实例的最大内存配置
maxmemory_human：以更直观的格式显示Redis实例的最大内存配置
maxmemory_policy：当达到maxmemory时的淘汰策略
mem_fragmentation_ratio：碎片率，used_memory_rss/ used_memory（正常情况下是1左右，如果大于1比如1.8说明内存碎片很严重了。）
mem_allocator：内存分配器
active_defrag_running：表示没有活动的defrag任务正在运行，1表示有活动的defrag任务正在运行（defrag:表示内存碎片整理）
lazyfree_pending_objects：0表示不存在延迟释放的挂起对象
重点：
Maxmemory && maxmemory_policy：
redis在占用的内存超过指定的maxmemory之后，通过maxmemory_policy确定redis是否释放内存以及如何释放内存。redis提供了8种内存超过限制之后的响应措施，分别如下：
1.volatile-lru(least recently used):最近最少使用算法，从设置了过期时间的键中选择空转时间最长的键值对清除掉；
2.volatile-lfu(least frequently used):最近最不经常使用算法，从设置了过期时间的键中选择某段时间之内使用频次最小的键值对清除掉；
3.volatile-ttl:从设置了过期时间的键中选择过期时间最早的键值对清除；
4.volatile-random:从设置了过期时间的键中，随机选择键进行清除；
5.allkeys-lru:最近最少使用算法，从所有的键中选择空转时间最长的键值对清除；
6.allkeys-lfu:最近最不经常使用算法，从所有的键中选择某段时间之内使用频次最少的键值对清除；
7.allkeys-random:所有的键中，随机选择键进行删除；
不做任何的清理工作，在redis的内存超过限制之后，所有的写入操作都会返回错误；但是读操作都能正常的进行
3、检查redis延迟情况
1）Slowlog（慢查询）
记录超过指定查询时间的系统，日志记录在内存中，有队列保存，超过最大队列长度最老的记录将会移除。
slowlog-log-slower-than 10000 单位微妙，超过这个执行时间将会记录日志
slowlog-max-len 128 队列长度，保留的最大条数
redis 127.0.0.1:6379> slowlog get 2
1) 1) (integer) 14 #唯一ID
2) (integer) 1309448221 #时间戳
3) (integer) 15 #时间毫秒
4) 1) "slowlog" #命令数组
2) "get"
3) "100"
5) "127.0.0.1:58217" #客户端IP:PORT 4.0以上版本
6) "work-123" #client setname
2）Latency Monitoring（延时监控）
A、 Measuring latency（测量延时）
redis-cli（客户端）提供了测量延迟的工具
使用--latency选项，cli将运行一个循环，将PING命令发送到Redis实例，并测量响应时间，每秒发送100次，统计时间以毫秒为单位。
使用--latency-history选项，每15秒新的采样会重新开始。
使用--latency-dist选项，使用彩色终端显示一系列延时特征。
使用--intrinsic-latency选项，将会检查cli客户端所在机器的延迟，即操作系统内核的延迟，后面为固有检查时间，一般100即可。
$ redis-cli --latency
min: 0, max: 1, avg: 0.19 (427 samples)
$ redis-cli --latency-history
min: 0, max: 1, avg: 0.14 (1314 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.18 (1299 samples) -- 15.00 seconds range
$ redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 16 microseconds.
Max latency so far: 50 microseconds.
Max latency so far: 53 microseconds.
Max latency so far: 83 microseconds.
Max latency so far: 115 microseconds.
B、Monitoring Latency （监控延时）
上述测量延迟客户端提供，个人感觉适合在集群建立处测量使用，当业务平稳运行时，如需监控业务请求的延迟，需要服务端内部机制。
首先需要修改配置开启延迟监控，官方建议虽然这个监控消耗的内存较少，但是如果redis集群运行良好，没有充分的理由开启监控提高redis集群对内存的占用率。
CONFIG SET latency-monitor-threshold 100 #单位毫秒，表示超过100毫秒的响应将会被监控，默认为0，表示关闭状态
Latency有五种子命令，在介绍他们之前，首先需要了解redis对不同的代码命令有不同的名称称之位事件，比如commend是一个测量可能为慢命令执行延时的事件，而fast-commend是监视O(1)和O(logN)命令的事件名称，又比如fork事件仅监视fork(2)系统调用。
Latency Latest
|
Latency History
|
Latency Reset
重置所有事件，丢弃当前记录延迟峰值，重置最大事件寄存器。
Latency Graph
图形化展示。
Latency Doctor
列出指导建议。
延迟排查参考文档：
http://ghoulich.xninja.org/2016/12/30/how-to-monitor-delay-issue-of-redis-system/
后续会继续补充，若有问题，欢迎指正，多谢~
