前言
本期继续分享关于Redis的知识，让你掌握在Redis变慢后不会慌张，冷静下来分析问题，为了方便阅读，文章分为上下两篇！
Redis 作为一款业内使用率最高的内存数据库，其拥有非常高的性能，单节点的QPS压测能达到18万以上。但也正因此如此，当应用访问 Redis 时，如果发现响应延迟变大时就会给业务带来非常大的影响。
比如在日常使用Redis时，肯定或多或少都遇到过下面这种问题：
图片
大部分兄弟面对这种访问变慢问题的排查就会一头雾水，不知道从哪里下手才好，因为不理解 Redis 的架构体系、核心功能的实现原理甚至一些命令的使用限制等。
今天就可能引起Redis变慢的原因一一分析，上篇看完后你将会形成一个比较完整的排查思路方案！
图片
Redis真的变慢了吗？
当我们遇到服务响应比较慢时，往往需要先排查内部原因，先弄清楚是不是Redis服务导致的，我们大部分系统可能涉及较长的链路和多服务、比如同一个接口会调用Mysql、MQ、Redis等其他三方组件和服务。
图片
因此需要确定是不是访问Redis服务变慢进而拖慢了整个服务的响应变慢，那就是先自查！🔔
- • 应用服务访问Redis的请求，记录下每次请求的响应延时，对比是否响应变长
- • 是否其他节点存在同样问题
假设我们确定了是Redis这条链路的问题！（如果不是Redis问题，文章就写不下去啦！！哈哈），这里同样存在两种可能 🤔
- • 业务端请求到Redis服务网络是否存在问题，存在网络延迟情况
- • Redis服务端本身出现问题，那需要进一步排查
redis命令执行过程-简约版.png
正常来说网络存在问题的可能性还是比较小的，因为如果存在网络问题，那么其他服务同样都会发生网络延迟情况，如果你想了解网络对 Redis 性能的影响，可以用 iPerf 这样的工具，测量从 Redis 客户端到服务器端的网络延迟，如果这个延迟有几十毫秒甚至是几百毫秒，就说明，Redis 运行的网络环境中很可能有大流量的其他应用程序在运行。
好，现在就剩下确定请求Redis的服务响应耗时变长了，也是文章的要讲的焦点问题，分析Redis变慢的原因，先查看Redis的响应延迟，可以对Redis 进行基准性能测试。
基准测试
基准性能就是指 Redis 在一台负载正常的机器上，其最大的响应延迟和平均响应延迟分别是多少
但是这又不能把别人或者官方的测试结果作为参考的指标，因为在不同的软硬件环境下，它的性能表现差别特别大，不同主频型号的CPU、不同的SSD硬盘，都会极大影响Redis的性能表现。
那该以什么标准来认定Redis变慢呢？
🚩🚩一般来说，如果你观察到的 Redis 运行时延迟是其基线性能的 2 倍及以上，就可以认定 Redis 变慢了
比如：执行以下命令，就可以测试出这个实例 60 秒内的最大响应延迟
[root@VM-12-10-opencloudos ~]# redis-cli --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 16 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 392 microseconds.
Max latency so far: 397 microseconds.
Max latency so far: 638 microseconds.
Max latency so far: 1869 microseconds.
Max latency so far: 2149 microseconds.
Max latency so far: 3026 microseconds.
Max latency so far: 6022 microseconds.
992399678 total runs (avg latency: 0.0605 microseconds / 60.46 nanoseconds per run).
Worst run took 99604x longer than the average latency.可以看到，此时的基线性能已经达到了 6.022ms，如果响应延时为12ms，那么基本可以认定为Redis变慢了，当然我测试的机器性能比较差，你们可以用自己的机器试试
注意：这个命令只在Redis所在的服务器上运行，避免网络对基线性能的影响，只考虑服务端软硬件环境的影响
到这里已经确定了是Redis服务变慢，那么是哪里变慢了呢，接下来将进行更详细的说明
Redis性能影响要素
分析可能影响因素很重要，是判断Redis性能的来源，如下图：
图片
在排除了网络因素之后，可以归纳为Redis自身命令操作、文件系统和操作系统三个大因素可能导致Redis性能存在问题。
接下来的文章将围绕这几个要素出发排查和解决性能影响问题
Redis性能问题分析
慢日志分析
图片
日志是个好东西，分析Mysql是否变慢我们可以通过查看慢日志的，同样的分析Redis慢，同样可以先看是否也存在慢日志 slowlog，这是基础和直观的方式。
Redis 提供的慢日志命令的统计功能，记录了有哪些命令在执行时耗时比较长，快速定位问题。
需要配置的参数：
- • slowlog-log-slower-than 配置对执行时间大于多少微秒(microsecond, 1秒=10^6微秒) 的命令进行记录。线上可以设置为1000微秒，也就是1毫秒。
- • slowlog-max-len 设置最大考验记录多少条记录。slow log 本身是一个先进先出(FIFO) 队列，当队列大小超过该配置的值时，最旧的一条日志将被删除。线上可以设置为1000以上。
配置如下：
//命令执行耗时超过 10 毫秒，记录慢日志
CONFIG SET slowlog-log-slower-than 10000
//只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500我们看下慢日志如何查询
127.0.0.1:6379> SLOWLOG get 3
1) (integer) 32693 # 慢日志ID
2) (integer) 1593763337 # 执行时间戳
3) (integer) 5299 # 执行耗时(微秒)
4) 1) "LRANGE" # 具体执行的命令和参数
2) "user_list:2000"
3) "0"
4) "-1注意慢日志功能比较粗糙简单，没有持久化记录能力，都是记录在内存中，没有持久化到文件中，所以一般都是设置保留有限的慢命令条数，如果慢命令比较多，会存在不能全部记录的情况
常见集中导致Redis变慢不合理的命令使用方式：
- • 获取Redis中的key时，避免使用keys *
- • 高频使用了 O(N) 及以上复杂度的命令，例如：SUNION、SORT、ZUNIONSTORE、ZINTERSTORE 聚合类命令
- • O(N) 复杂度的命令，但 N 的值非常大，比如：hgetall、smembers、lrange、zrange等命令
这种情况下我们可以将复杂的聚合放在业务端处理，并且每次尽量少获取大量数据
BigKey问题
图片
分析慢日志时发现很多请求并不是复杂度高的命令，都是一些del、set、hset等的低复杂度命令，那么就要评估是否写入了大key，也就是BigKey。
Bigkey 是指当 Redis 的字符串类型过大，非字符串类型元素过多 (hash，list，set等存储中value值过多)
bigkey会带来如下问题：
图片
此时我们可以回想和检查业务代码，查看是否存在写入bigkey的情况，评估好单个key的数据大小，避免存在过大数据。
除了代码自查之外，可以使用命令查，如下：
[root@VM-12-10-opencloudos ~]# redis-cli -h 127.0.0.1 -p 6379 --bigkeys
-------- summary -------
Sampled 15 keys in the keyspace!
Total key length in bytes is 162 (avg len 10.80)
//最大的数据值
Biggest string found 'page4:20230921' has 12304 bytes
Biggest list found 'article:100' has 8 items
Biggest set found 'union:65:67' has 7 members
Biggest hash found 'page2:20230921' has 2 fields
Biggest zset found 'likeTopList' has 2 members
//平均值
6 strings with 24778 bytes (40.00% of keys, avg size 4129.67)
1 lists with 8 items (06.67% of keys, avg size 8.00)
6 sets with 24 members (40.00% of keys, avg size 4.00)
1 hashs with 2 fields (06.67% of keys, avg size 2.00)
1 zsets with 2 members (06.67% of keys, avg size 2.00)--i 参数，降低扫描的执行速度，比如 --i 0.1 表示 100 毫秒执行一次，降低扫描过程中对 Redis运行实例的影响。
--bigkeys命令原理解析
Redis 在内部执行了 SCAN 命令，遍历整个实例中所有的 key 然后针对 key 的类型，分别执行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令，来获取 String 类型的长度、容器类型（List、Hash、Set、ZSet）的元素个数
面对bigkey问题，我们可以这些方面下手去处理：
key集中过期
不知道大家是否遇到过，在某个时间点Redis突然出现一波延时，而且报慢的，有时候超时还有时间规律
如果出现这种情况，就需要考虑是否存在大量key集中过期的情况，因为大量的key在某个固定时间点集中过期，在这个时间点访问Redis时，就有可能导致延迟增加。
图片
如果出现了这种情况，那么需要从两个方面排查一下：
- • 业务逻辑是否有定时任务的脚本程序，定期操作key
- • Redis的Key数量出现集中过期清理
程序层面这个我们自己排查就好了，这里主要看下为什么Key数量集中过期，集中过期为啥造成了Redis访问变慢
Redis的Key过期策略是怎样的？
被动过期：只有应用发起访问某个key 时，才判断这个key是否已过期，如果已过期，则从Redis中删除
主动过期：在Redis 内部维护了一个定时任务，默认每隔 100 毫秒（1秒10次）从全局的过期哈希表中随机取出 20 个 key，判断然后删除其中过期的 key，如果过期 key 的比例超过了 25%，则继续重复此过程，直到过期 key 的比例下降到 25% 以下，或者这次任务的执行耗时超过了 25 毫秒，才会退出循环
注意，这个主动过期 key 的定时任务，是在 Redis 主线程中执行的
这也是我们主要关注的问题 【主动过期清理】，那为什么会导致Redis延时呢？
因为主动过期是在Redis 主线程中执行的，也就意味着会阻塞正常的请求命令。
进一步说就是如果在执行主动过期的过程中，出现了需要大量删除过期 key 的请求，那么此时应用程序在访问 Redis 时，必须要等待这个过期任务执行结束，Redis 才可以继续处理新请求，这也就是为什么此时访问Redis会突然出现延迟。
即使删除过期key是耗时的，也不会记录在slowlog慢日志中哦！
这里大家估计又有疑惑了，这不是慢了吗？
别急，这是因为slowlog记录的是Redis服务端在命令执行前后计算每条命令的执行时长，而过期清理的时候Redis是登录状态，还不能处理客户端发过来的请求，也就是在命令执行之前进行的。
这种情况我们可以这样处理：
- • 业务Key设置过期时间时，加上一个随机过期时间段，比如1分钟
- • 通过执行info命令获取过期Key数量【expired_keys】的统计值
- • Redis 4.0以上版本，开启 lazy-free 机制，把释放内存的操作放到后台线程中执行，避免阻塞主线程
预估内存不足
我们知道服务器的内存是有限的，这个是既定事实，而且使用Redis时都会配置当前实例可用的最大内存maxmemory和数据自动淘汰策略
maxmemory : 默认为0 不限制。
//获取maxmemory配置的大小
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "0" //默认值是0
//可以在redis.conf中配置
maxmemory 1024mb当使用的内存达到了 maxmemory 后，即使配置了自动淘汰策略，仍然会在之后每次写入新数据时，操作延迟都会变长。
原因在于，当 Redis 内存达到 maxmemory 后，每次写入新的数据之前，Redis 必须先从实例中踢出一部分数据，让整个实例的内存维持在 maxmemory 之下，然后才能把新数据写进来。
图片
Redis的常用 allkeys-lru / volatile-lru 的淘汰策略
volatile-lru ：利用LRU算法移除设置过过期时间的key
allkeys-lru ：利用LRU算法移除任何key （和上一个相比，删除的key包括设置过期时间和不设置过期时间的）
Redis采用近似LRU算法，实现逻辑是什么样的？
1：每次从实例中随机选择一个key (样本集)，并从样本集中挑选最长时间未使用的 key 淘汰，剩下的放入待淘汰池
2：再次随机获取一批样本集，并与第一步池子的key比较，进而进行淘汰最少访问的key，剩下的放入待淘汰池
3：循环往复上面两个操作步骤，直到实例内存降到maxmemory值为止
假如我们淘汰策略删除的是 bigkey，那么耗时还更久，可想而知 bigkey对Redis的危害应该很大
不过针对内存不足问题，我们也可以进行一个优化措施：
1：避免存储 bigkey，降低释放内存的耗时
2：合理预估内存占用，避免达到内存的使用上限
- • 根据写入Key的类型、数量及平均大小计算预估
- • 写入一小部分比例的真实业务数据，然后进行预估
3：Redis 4.0 及以上版本，开启 layz-free 机制，把淘汰 key 释放内存的操作放到后台线程中执行
实际请求量超预期
一个系统处理请求是有上限的。Redis虽然处理速度很快，但是也有上限。因此在流量暴增的时候，会比较快达到Redis的处理瓶颈，这个时候整个系统也会变慢，出现slowlog等。
这个现象也比较好观察，可以看看实例的cpu情况，如果持续100%，基本可以判定达到处理上限了。
这种情况最好我们要结合云监控，对CPU使用率、访问的QPS进行监控，发现系统瓶颈，看是否进行扩容和调整。
ok，关于Redis变慢问题的上半部分就分享到这里了，下期将继续更新其他可能导致Redis变慢的情况。
