Redis变慢？深入浅出Redis性能诊断系列文章（一）

　　（本文首发于＂数据库架构师＂公号，订阅＂数据库架构师＂公号，一起学习数据库技术）
　　Redis 作为一款业内使用率最高的内存数据库，其拥有非常高的性能，单节点的QPS压测能达到18万以上。但也正因此如此，当应用访问 Redis 时，如果发现响应延迟变大时就会给业务带来非常大的影响。
　　比如在日常使用Redis时，肯定或多或少都遇到过下面这种问题：为什么Redis服务过去一直很稳定，突然从今天某个时间点开始变慢了？ 为什么访问Redis相同的命令，有时响应很快，有时却非常慢？ 为什么访问Redis突然卡住了，过一会又自动恢复了，这也导致业务请求出现很多的毛刺？ …
　　如果不理解 Redis 的架构体系、核心功能的实现原理甚至一些命令的使用限制等，那么这种访问变慢问题的排查就会一头雾水，不知道从哪里下手才好。
　　本文基于多年使用和运维管理Redis的经验，详细梳理了可能引起Redis性能问题的原因并剖析对应的解决方案，也希望这一系列的文章能帮助大家更加合理的使用 Redis ，快速的定位并解决问题。
　　一、Redis访问架构链路分析
　　首先，在深入分析Redis服务前，需要弄清楚是不是真的Redis访问变慢了。
　　如果我们发现自己的应用服务响应延迟变长，我们首先要排查应用内部，确认是不是访问Redis路径变慢进而拖慢了整个服务的响应吞吐。
　　这里有两个比较关键的自查：对于应用服务访问Redis的请求，记录下每次请求的响应延时（比如使用分布式链路跟踪系统等），看看是不是访问Redis响应时间变长了； 排查应用服务的多个节点，看看是不是每个节点都有问题，还是仅仅一个出现了问题。
　　这两个是后续深入分析Redis服务问题前的关键自查，事半功倍！
　　对于第一点从应用到Redis这条链路变慢的原因可能有如下两个：应用到Redis服务之间的链路出现问题了，比如Redis所在服务器网络负载过高丢包、交换机问题、Proxy变慢等； Redis本身确实因为一些原因变慢了。
　　一般服务器层面都会有相关监控，网络的问题很容易就会发现，比如网卡打满、网卡降频【万兆降为千兆】等。
　　对于Redis访问链路的响应时间则可以做个模拟监控，如下Redis访问架构，应用程序经过域名系统、VIP系统，最后才到Redis所在的服务器，这种情况下则分别可以模拟 请求域名、请求VIP、请求直连Redis Server三条路径来评估响应时间是否确实变长了。
　　下面是另外一种Redis架构，访问路径又有不同，那么排查的方向也不会不同。
　　二、Redis性能基准测评
　　如果核查发现确实是请求Redis的服务响应耗时变长了，那么此刻就可以把问题分析的焦点放到Redis上了。
　　下面我们重点分析下Redis性能问题。
　　首先，需要对 Redis 进行基准的性能测试，了解我们的 Redis 服务在当前环境服务器上的基准性能。
　　什么是基准性能？
　　简单来讲，基准性能就是指在一台负载正常的服务器上，访问Redis的最大的响应延迟和平均响应延迟分别是怎样的？
　　为什么要测试基准性能？参考官方提供的响应延迟测试，来判断自己的 Redis服务是否变慢不行吗？
　　答案是不行的。
　　因为Redis 在不同的软硬件环境下，它的性能表现差别特别大，不同主频型号的CPU、不同的SSD硬盘，都会极大影响Redis的性能表现。服务器配置比较低时延迟为 10ms 时，才认为 Redis响应变慢了，但是如果配置比较高，那么可能延迟是 1ms 时就可以认为 Redis 变慢了。
　　所以，只有了解我们的 Redis 在生产环境服务器上的基准性能，才能进一步评估，当其延迟达到什么程度时，才认为 Redis 确实变慢了。
　　Redis自带的工具可以帮助我们完成这种测评，如下介绍两种基准性能测试的方式。
　　方式一：redis-cli --intrinsic-latency
　　为了避免业务测试服务器到 Redis 服务器之间的网络延迟，需要直接在 Redis 服务器上测试实例的响应延迟情况。执行以下命令，就可以测试出这个实例 120 秒内的最大响应延迟：
　　shell> redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 120
　　Max latency so far: 4 microseconds.
　　Max latency so far: 5 microseconds.
　　Max latency so far: 15 microseconds.
　　Max latency so far: 23 microseconds.
　　Max latency so far: 64 microseconds.
　　Max latency so far: 196 microseconds.
　　Max latency so far: 245 microseconds.
　　Max latency so far: 246 microseconds.
　　Max latency so far: 254 microseconds.
　　Max latency so far: 259 microseconds.
　　29298480 total runs (avg latency: 4.0958 microseconds / 40957.76 nanoseconds per run).
　　Worst run took 63x longer than the average latency.
　　从输出结果可以看到，这 120 秒内的最大响应延迟为 259 微秒（0.259毫秒）。
　　方式二：redis-benchmark
　　Redis-benchmark是Redis官方自带的Redis性能测试工具，可以有效的测试Redis服务的性能.
　　shell> redis-benchmark -h 127.0.0.1 -p 6379 -t set,get -c 500 -n 100000
　　====== SET ======
　　100000 requests completed in 1.02 seconds
　　500 parallel clients
　　3 bytes payload
　　keep alive: 1
　　0.00% <= 1 milliseconds
　　0.05% <= 2 milliseconds
　　99.09% <= 3 milliseconds
　　99.88% <= 4 milliseconds
　　100.00% <= 4 milliseconds
　　97847.36 requests per second
　　====== GET ======
　　100000 requests completed in 1.02 seconds
　　500 parallel clients
　　3 bytes payload
　　keep alive: 1
　　0.00% <= 1 milliseconds
　　0.05% <= 2 milliseconds
　　99.29% <= 3 milliseconds
　　99.92% <= 4 milliseconds
　　100.00% <= 4 milliseconds
　　97656.24 requests per second
　　该命令对set和get命令的操作响应时间进行测评，并发500个执行10w次操作，从输出结果可以看到，set的QPS达到了97847，响应时间都在4ms以内；get的QPS达到了97656，最大响应时间也在4ms以内；
　　了解了基准性能测试方法，那么我们就可以按照以下几步，来判断 Redis 是否真的变慢了：在相同配置的服务器上，测试一个正常 Redis 实例的基准性能 找到可能变慢的 Redis 实例，测试这个实例的基准性能 对比这个实例的运行延迟与正常 Redis 基准性能，如果性能差距在两倍以上，就可以认为这个 Redis 服务确实响应变慢了
　　如果确认是 Redis服务变慢了，那如何排查是哪里发生了问题呢？后面的系列文章将从多个维度来一步步详细分析，欢迎关注。
　　如果这篇文章对你有帮助，还请帮忙 点赞、转发  一下，你的支持会激励我输出更多高质量的文章，非常感谢！
　　如果你还想看更多优质文章，欢迎关注我的公号「数据库架构师」，提升数据库技能。