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、请求直连RedisServer三条路径来评估响应时间是否确实变长了。
　　下面是另外一种Redis架构，访问路径又有不同，那么排查的方向也不会不同。
　　二、Redis性能基准测评
　　如果核查发现确实是请求Redis的服务响应耗时变长了，那么此刻就可以把问题分析的焦点放到Redis上了。
　　下面我们重点分析下Redis性能问题。
　　首先，需要对Redis进行基准的性能测试，了解我们的Redis服务在当前环境服务器上的基准性能。
　　什么是基准性能？
　　简单来讲，基准性能就是指在一台负载正常的服务器上，访问Redis的最大的响应延迟和平均响应延迟分别是怎样的？
　　为什么要测试基准性能？参考官方提供的响应延迟测试，来判断自己的Redis服务是否变慢不行吗？
　　答案是不行的。
　　因为Redis在不同的软硬件环境下，它的性能表现差别特别大，不同主频型号的CPU、不同的SSD硬盘，都会极大影响Redis的性能表现。服务器配置比较低时延迟为10ms时，才认为Redis响应变慢了，但是如果配置比较高，那么可能延迟是1ms时就可以认为Redis变慢了。
　　所以，只有了解我们的Redis在生产环境服务器上的基准性能，才能进一步评估，当其延迟达到什么程度时，才认为Redis确实变慢了。
　　Redis自带的工具可以帮助我们完成这种测评，如下介绍两种基准性能测试的方式。
　　方式一：rediscliintrinsiclatency
　　为了避免业务测试服务器到Redis服务器之间的网络延迟，需要直接在Redis服务器上测试实例的响应延迟情况。执行以下命令，就可以测试出这个实例120秒内的最大响应延迟：
　　shellredisclih127。0。0。1p6379intrinsiclatency120
　　Maxlatencysofar：4microseconds。
　　Maxlatencysofar：5microseconds。
　　Maxlatencysofar：15microseconds。
　　Maxlatencysofar：23microseconds。
　　Maxlatencysofar：64microseconds。
　　Maxlatencysofar：196microseconds。
　　Maxlatencysofar：245microseconds。
　　Maxlatencysofar：246microseconds。
　　Maxlatencysofar：254microseconds。
　　Maxlatencysofar：259microseconds。
　　29298480totalruns（avglatency：4。0958microseconds40957。76nanosecondsperrun）。
　　Worstruntook63xlongerthantheaveragelatency。
　　从输出结果可以看到，这120秒内的最大响应延迟为259微秒（0。259毫秒）。
　　方式二：redisbenchmark
　　Redisbenchmark是Redis官方自带的Redis性能测试工具，可以有效的测试Redis服务的性能。
　　shellredisbenchmarkh127。0。0。1p6379tset，getc500n100000
　　SET
　　100000requestscompletedin1。02seconds
　　500parallelclients
　　3bytespayload
　　keepalive：1
　　0。001milliseconds
　　0。052milliseconds
　　99。093milliseconds
　　99。884milliseconds
　　100。004milliseconds
　　97847。36requestspersecond
　　GET
　　100000requestscompletedin1。02seconds
　　500parallelclients
　　3bytespayload
　　keepalive：1
　　0。001milliseconds
　　0。052milliseconds
　　99。293milliseconds
　　99。924milliseconds
　　100。004milliseconds
　　97656。24requestspersecond
　　该命令对set和get命令的操作响应时间进行测评，并发500个执行10w次操作，从输出结果可以看到，set的QPS达到了97847，响应时间都在4ms以内；get的QPS达到了97656，最大响应时间也在4ms以内；
　　了解了基准性能测试方法，那么我们就可以按照以下几步，来判断Redis是否真的变慢了：在相同配置的服务器上，测试一个正常Redis实例的基准性能找到可能变慢的Redis实例，测试这个实例的基准性能对比这个实例的运行延迟与正常Redis基准性能，如果性能差距在两倍以上，就可以认为这个Redis服务确实响应变慢了
　　如果确认是Redis服务变慢了，那如何排查是哪里发生了问题呢？后面的系列文章将从多个维度来一步步详细分析，欢迎关注。
　　如果这篇文章对你有帮助，还请帮忙点赞、转发一下，你的支持会激励我输出更多高质量的文章，非常感谢！
　　如果你还想看更多优质文章，欢迎关注我的公号数据库架构师，提升数据库技能。