简介
使用Redis的小伙伴们都希望能够获取最大的性能收获，不管什么操作，越快越好。
然而，在实际的使用中，却发现有些指令的执行并不像想象中的那样flash。
怎么办？我觉得首先需要回答下面这个问题：
到底是Redis本身慢了，还是业务逻辑性能出了问题？
本文主要针对第一种情况，来进行一下Redis延迟的基准性能测试。
如果基准测试没有问题，那么Redis自身大概是没有什么问题的，就要检查一下业务逻辑或者使用的指令是否是慢指令了。
基本延迟
下面的测试都是使用 redis-cli 客户端进行，基础命令如下：
redis-cli -h 192.168.1.66 -p 6379
直接使用该客户端可以避免其他因素对测试结果的影响。
理论上，如果是在本机测试，结果就是Redis自身延迟。如果不是本机，则多了一次网络传输的延迟（这个需要自行评估）。
基础的延迟测试命令如下：
redis-cli -h 127.0.0.1 -p 6379 --latency
该命令会统计三个延迟指标：最小值（min），最大值（max）和平均值（avg），单位是ms。
通过 ctrl + c 结束命令。
说明：
该指令统计的是 PING 指令的耗时其中不包括连接建立时间连接的是本地Redis服务，也不包含网络传输时间
示例结果如下：
% redis-cli -h 127.0.0.1 -p 6379 --latency
min: 0, max: 1, avg: 0.16 (3054 samples)
可见平均延迟为0.16ms，即160us，共统计了3054个样本数据。
在不同的服务器上安装的Redis，性能会有不同。
比如我同样在虚拟机上跑了一下：
min: 0, max: 1, avg: 0.23 (3123 samples)
结果要比物理机上差一些。
也可以使用以下命令测试：
redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 10
该命令可以按间隔打印结果，间隔时间由-i参数指定，默认15s。
物理机上测试如下：
% redis-cli --latency-history -i 10
min: 0, max: 1, avg: 0.16 (974 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.18 (972 samples) -- 10.00 seconds range
min: 0, max: 1, avg: 0.18 (972 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.17 (973 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.16 (972 samples) -- 10.01 seconds range
虚拟机测试结果：
# redis-cli -p 7000 --latency-history -i 10
min: 0, max: 1, avg: 0.24 (969 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.22 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (966 samples) -- 10.00 seconds range
固有延迟
Redis还提供了测试固有延迟基准的方法：
redis-cli --intrinsic-latency 100
注意：
100指的是测试时长为100s，可以任意指定该指令测试的是操作系统内核调用进程的最大延迟该延迟是固有的，业务延迟不可能比它还小。可以把它作为延迟的最低基准该指令需要在运行Redis服务的机器上运行该指令并不会真正连接Redis服务在不同的系统上，或者在同一系统的不同时间段测试时，都可能得到不同的结果系统负载大小对测试结果有较大影响
物理机上测试结果：
% redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 6 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 10 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 153 microseconds.
Max latency so far: 155 microseconds.
Max latency so far: 156 microseconds.
Max latency so far: 176 microseconds.
Max latency so far: 177 microseconds.
Max latency so far: 178 microseconds.
1838554810 total runs (avg latency: 0.0544 microseconds / 54.39 nanoseconds per run).
Worst run took 3273x longer than the average latency.
虚拟机上测试结果：
# redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 13 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 23 microseconds.
Max latency so far: 30 microseconds.
Max latency so far: 39 microseconds.
Max latency so far: 65 microseconds.
Max latency so far: 74 microseconds.
Max latency so far: 138 microseconds.
Max latency so far: 144 microseconds.
Max latency so far: 160 microseconds.
Max latency so far: 188 microseconds.
Max latency so far: 190 microseconds.
Max latency so far: 243 microseconds.
Max latency so far: 364 microseconds.
829284793 total runs (avg latency: 0.1206 microseconds / 120.59 nanoseconds per run).
Worst run took 3019x longer than the average latency.
定位延迟
如果发现延迟较大，有一些方法可以定位延迟出现的情况：
确保没有执行慢指令（慢指令会导致Redis服务阻塞），可以使用 slowlog 查看，具体：https://redis.io/commands/slowlog关闭内核Transparent huge pages：echo never > /sys/kernel/mm/transparent_hugepage/enabled（需要重启Redis服务）测试固有延迟（如果固有延迟已经较大，可能是操作系统负载较高或性能不佳）使用Redis的Latency Monitoring功能监测延迟情况，具体：https://redis.io/topics/latency-monitor
小结
有了各种客户端的支持，Redis是极容易使用的。
但是要把Redis的优势完全地发挥利用出来，还是需要好好研究一番的。
Redis也不是完美的，所以有必要了解避免踩坑的方法。
避其缺陷，扬其优势，方能为项目所用。
关于延迟分析的更多内容，可参考：https://redis.io/topics/latency