运维和开发慌了，Redis突然 "慢" 了，到底谁背锅？

前言

众所周知Redis是单线程，有着极快的响应速度，但是有一天Redis突然变"慢"了，运维甚至开发都慌了，开始一系列的骚操作了，但是一点效果都没有，why？

遇到问题不要慌，首先需要确定的是：Redis真的变慢了吗？

今天陈某就来介绍下以什么标准为基线判断Redis变慢了？

Redis真的变慢了？

我们知道一个应用程序在服务器上运行，它的运行快慢和硬件乃至底层操作系统都有巨大的关系，因此Redis响应慢了就真的是Redis的锅？

如何判断Redis是不是真的变慢了？一个最直接方法：查看Redis响应延迟

大部分情况下Redis的延迟很低，但是在某些时刻延迟突然很高，当你发现Redis命令的执行时间突然增长到几秒，基本就可以认定Redis变慢了。

但是不同的软硬件环境下，延迟时间的标准却是大相径庭，比如在服务器A上延迟为1s时基本就能判定Redis变慢了，在较好配置的服务器B上甚至延迟10ms就可以判定Redis变慢了。

显然上述的标准很难判断，此时只能通过Redis基线性能来判断。

基线性能：系统在低压力、无干扰下的基本性能，这个性能只由当前的软件配置决定。

那么如何确定这个基线性能呢？很多人疑惑了？

从 2.8.7 版本开始，redis-cli 命令提供了–intrinsic-latency 选项，可以用来监测和统计测试期间内的最大延迟，这个延迟可以作为 Redis 的基线性能。其中，测试时长可以用–intrinsic-latency 选项的参数来指定（一般情况下120s足够监测到最大延迟了）。

本机测试（未通过客户端）的监测命令如下：

redis-cli --intrinsic-latency 120

Max latency so far: 1 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 29 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 36 microseconds.
Max latency so far: 42 microseconds.
Max latency so far: 44 microseconds.
Max latency so far: 62 microseconds.
Max latency so far: 599 microseconds.
Max latency so far: 613 microseconds.
Max latency so far: 8158 microseconds.
Max latency so far: 13426 microseconds.
Max latency so far: 16073 microseconds.
Max latency so far: 19587 microseconds.
Max latency so far: 22988 microseconds.

1982697419 total runs (avg latency: 0.0605 microseconds / 605.24 nanoseconds per run).
Worst run took 379819x longer than the average latency.

发现最大的延迟22988微秒，因此这里的基线性能为22988微秒。

基线性能只和操作系统、硬件配置相关，因此这里可以结合基线性能判断Redis是否真的变慢了？

一般运行时延迟达到基线性能的2倍以上则可判定Redis变慢了。

注意：基线性能非常重要，尤其对于虚拟化的环境（虚拟机、容器），他们的基线性能相对很高，因此结合基线性能判断是必要的。

切记：一定要在本机上运行测试命令，如果通过客户端则需要考虑网络性能的影响。

现在有很多网络性能的测量工具，比如iperf，如果发现网络阻塞了，此时就需要联络公司的网络工程师了。

总结

本文介绍了如何判断Redis变慢的标准，即是基线性能，只有结合基线性能和运行延迟相对比，大概超过2倍以上则可判断Redis真的变慢了。

另外，作者已经完成了两个专栏的文章Mybatis进阶、Spring Boot 进阶 ，已经将专栏文章整理成书，有需要的公众号回复关键词Mybatis 进阶、Spring Boot 进阶免费获取。