Redis变慢?深入浅出Redis性能诊断系列文章(一)

(本文首发于“数据库架构师”公号,订阅“数据库架构师”公号,一起学习数据库技术)
 
Redis 作为一款业内使用率最高的内存数据库,其拥有非常高的性能,单节点的QPS压测能达到18万以上。但也正因此如此,当应用访问 Redis 时,如果发现响应延迟变大时就会给业务带来非常大的影响。
比如在日常使用Redis时,肯定或多或少都遇到过下面这种问题:
  • 为什么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性能诊断系列文章(一)插图1
 下面是另外一种Redis架构,访问路径又有不同,那么排查的方向也不会不同。
Redis变慢?深入浅出Redis性能诊断系列文章(一)插图2
二、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%

0.05%

99.09%

99.88%

100.00%

97847.36 requests per second
 
====== GET ======
100000 requests completed in 1.02 seconds
500 parallel clients
3 bytes payload
keep alive: 1
 
0.00%

0.05%

99.29%

99.92%

100.00%

97656.24 requests per second
该命令对set和get命令的操作响应时间进行测评,并发500个执行10w次操作,从输出结果可以看到,set的QPS达到了97847,响应时间都在4ms以内;get的QPS达到了97656,最大响应时间也在4ms以内;
了解了基准性能测试方法,那么我们就可以按照以下几步,来判断 Redis 是否真的变慢了:
  • 在相同配置的服务器上,测试一个正常 Redis 实例的基准性能
  • 找到可能变慢的 Redis 实例,测试这个实例的基准性能
  • 对比这个实例的运行延迟与正常 Redis 基准性能,如果性能差距在两倍以上,就可以认为这个 Redis 服务确实响应变慢了 
如果确认是 Redis服务变慢了,那如何排查是哪里发生了问题呢?后面的系列文章将从多个维度来一步步详细分析,欢迎关注。
 
如果你还想看更多优质文章,欢迎关注我的公号「数据库架构师」,提升数据库技能。

如果我的文章对你有所帮助,还请帮忙点赞、在看、转发一下,你的支持会激励我输出更高质量的文章,非常感谢!

posted @
2022-09-13 22:12 
数据库架构师 
阅读(0
评论(0
编辑 
收藏 
举报





文章来源于互联网:Redis变慢?深入浅出Redis性能诊断系列文章(一)

THE END
分享
二维码