当前位置：首页 > 后端开发 > 正文内容

第78篇 Redis常见推迟问题

邻居的猫1个月前 (12-09)后端开发1268

运用复杂度高的指令

Redis供给了慢日志指令的核算功用
首要设置Redis的慢日志阈值，只要超越阈值的指令才会被记载，这儿的单位是奇妙，例如设置慢日志的阈值为5毫秒，一起设置只保存最近1000条慢日志记载：

# 指令履行超越5毫秒记载慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保存最近1000条慢日志
CONFIG SET slowlog-max-len 1000

履行SLOWLOG get 5查询最近5条慢日志

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 履行时刻
   3) (integer) 5299        # 履行耗时(微秒)
   4) 1) "LRANGE"           # 详细履行的指令和参数
	  2) "user_list_2000"
	  3) "0"
	  4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
	  2) "book_price_1000"
...

经过检查慢日志记载，就能够知道在什么时刻履行哪些指令比较耗时，假如服务恳求量并不大，但Redis实例的CPU运用率很高，很有或许便是运用了复杂度高的指令导致的。

比方常常运用O(n)以上复杂度的指令，由于Redis是单线程履行指令，因而这种状况Redis处理数据时就会很耗时。例如

sort：对列表（list）、调集（set）、有序调集（sorted set）中的元素进行排序。在最简略的状况下（没有权重、没有形式、没有 LIMIT），SORT 指令的时刻复杂度近似于 O(n*log(n))
sunion：用于核算两个或多个调集的并集。时刻复杂度能够描绘为 O(N)，其间 **N **是一切参加运算调集的元素总数。假如有多个调集，每个调集有不同数量的元素参加运算，那么复杂度会是一切这些调集元素数量的总和。
zunionstore：用于核算一个或多个有序调集的并集，并将成果存储到一个新的有序调会集。在最简略的状况下，ZUNIONSTORE 指令的时刻复杂度是 O(N*log(N))，其间 N 是一切参加核算的调会集元素的总数。
keys * ：获取一切的 key 操作；复杂度O(n)，数据量越大履行速度越慢；能够运用scan指令代替
Hgetall：回来哈希表中一切的字段和；
smembers：回来调会集的一切成员；

解决计划便是，不运用这些复杂度较高的指令，而且一次不要获取太多的数据，每次尽量操作少数的数据，让Redis能够及时处理回来

存储大key

假如查询慢日志发现，并不是复杂度较高的指令导致的，例如都是SET、DELETE操作呈现在慢日志记载中，那么就要置疑是否存在Redis写入了大key的状况。

多大才算大

假如一个 key 对应的 value 所占用的内存比较大，那这个 key 就能够看作是 bigkey。

String 类型的 value 超越 1MB
复合类型（List、Hash、Set、Sorted Set 等）的 value 包括的元素超越 5000 个（不过，关于复合类型的 value 来说，不必定包括的元素越多，占用的内存就越多）。

发生原因

程序设计不妥，比方直接运用 String 类型存储较大的文件对应的二进制数据。
关于事务的数据规划考虑不周到，比方运用调集类型的时分没有考虑到数据量的快速增长。
未及时整理废物数据，比方哈希中冗余了许多的无用键值对。

形成的问题

客户端超时堵塞：由于 Redis 履行指令是单线程处理，然后在操作大 key 时会比较耗时，那么就会堵塞 Redis，从客户端这一视角看，便是很久很久都没有呼应。
网络堵塞：每次获取大 key 发生的网络流量较大，假如一个 key 的巨细是 1 MB，每秒拜访量为 1000，那么每秒会发生 1000MB 的流量，这关于一般千兆网卡的服务器来说是灾难性的。
作业线程堵塞：假如运用 del 删去大 key 时，会堵塞作业线程，这样就没办法处理后续的指令。
耐久化堵塞（磁盘IO）：对AOF 日志的影响
- - 运用Always 战略的时分，主线程在履行完指令后，会把数据写入到 AOF 日志文件，然后会调用 fsync() 函数，将内核缓冲区的数据直接写入到硬盘，比及硬盘写操作完结后，该函数才会回来。因而当运用 Always 战略的时分，假如写入是一个大 Key，主线程在履行 fsync() 函数的时分，堵塞的时刻会比较久，由于当写入的数据量很大的时分，数据同步到硬盘这个进程是很耗时的。
- - 别的两种战略都不影响主线程

大 key 形成的堵塞问题还会进一步影响到主从同步和集群扩容。

怎么发现 bigkey？

运用 Redis 自带的 --bigkeys 参数来查找：这个指令会扫描(Scan) Redis 中的一切 key ，会对 Redis 的功用有一点影响，最好挑选在从节点上履行该指令，由于主节点上履行时，会堵塞主节点。而且，这种方法只能找出每种数据结构 top 1 bigkey（占用内存最大的 String 数据类型，包括元素最多的复合数据类型）。但是，一个 key 的元素多并不代表占用内存也多，需求咱们依据详细的事务状况来进一步判别。
Redis 自带的 SCAN 指令：SCAN 指令能够依照必定的形式和数量回来匹配的 key。获取了 key 之后，能够运用 STRLEN、HLEN、LLEN等指令回来其长度或成员数量。

凭借开源东西剖析 RDB 文件：这种计划的条件是Redis 选用的是 RDB 耐久化。网上有现成的东西：
- redis-rdb-tools：Python 言语写的用来剖析 Redis 的 RDB 快照文件用的东西
- rdb_bigkeys：Go 言语写的用来剖析 Redis 的 RDB 快照文件用的东西，功用更好。

怎么处理 bigkey？

删去大 key：删去大 key 时主张选用分批次删去和异步删去的方法进行；
- 由于删去大 key开释内存仅仅第一步，为了愈加高效地办理内存空间，在应用程序开释内存时，操作体系需求把开释掉的内存块刺进一个闲暇内存块的链表，以便后续进行办理和再分配。这个进程自身需求必守时刻，而且会堵塞当时开释内存的应用程序。
- 所以，假如一会儿开释了许多内存，闲暇内存块链表操作时刻就会添加，相应地就会形成 Redis 主线程的堵塞，假如主线程发生了堵塞，其他一切恳求或许都会超时，超时越来越多，会形成 Redis 衔接耗尽，发生各种反常。
切割 bigkey：将一个 bigkey 切割为多个小 key。例如，将一个含有上万字段数量的 Hash 依照必定战略（比方二次哈希）拆分为多个 Hash。
手动整理：Redis 4.0+ 能够运用 UNLINK 指令来异步删去一个或多个指定的 key。Redis 4.0 以下能够考虑运用 SCAN 指令结合 DEL 指令来分批次删去。
选用适宜的数据结构：例如，文件二进制数据不运用 String 保存、运用 HyperLogLog 核算页面 UV、Bitmap 保存状况信息（0/1）。
敞开 lazy-free（慵懒删去/推迟开释）：lazy-free 特性是 Redis 4.0 开端引进的，指的是让 Redis 选用异步方法推迟开释 key 运用的内存，将该操作交给独自的子线程处理，防止堵塞主线程。

会集过期

Redis的过期战略选用守时过期+懒散过期两种战略：

守时过期：Redis内部保护一个守时使命，默许每秒进行10次(也便是每隔100毫秒一次)过期扫描，从过期字典中随机取出20个key，删去过期的key，假如过期key的份额还超越25%，则持续获取20个key，删去过期的key，循环往复，直到过期key的份额下降到25%或许这次使命的履行耗时超越了25毫秒，才会退出循环
懒散过期：只要当拜访某个key时，才判别这个key是否已过期，假如现已过期，则从实例中删去

Redis的守时删去战略是在Redis主线程中履行的，也便是说假如在履行守时删去的进程中，呈现了需求许多删去过期key的状况，那么在事务拜访时，有必要等这个守时删去使命履行完毕，才能够处理事务恳求。此刻就会呈现，事务拜访延时增大的问题，最大推迟为25毫秒。

为了尽量防止这个问题，在设置过期时刻时，能够给过期时刻设置一个随机规模，防止同一时刻过期。

伪代码能够这么写：

# 在过期时刻点之后的5分钟内随机过期掉
redis.expireat(key, expire_time + random(300))

实例内存到达上限

出产中会给内存设置上限maxmemory，当数据内存到达 maxmemory 时，便会触发redis的内存筛选战略

那么当实例的内存到达了maxmemory后，就会发现之后每次写入新的数据，就好像变慢了。导致变慢的原因是，当Redis内存到达maxmemory后，每次写入新的数据之前，会先依据内存筛选战略先踢出一部分数据，让内存维持在maxmemory之下。

而内存筛选战略就决议这个踢出数据的时刻长短：

最常运用的一般是allkeys-lru或volatile-lru战略，Redis 内存筛选时，会运用随机采样的方法来筛选数据，它是随机取 5 个值 (此值可装备) ，然后筛选一个最少拜访的key，之后把剩余的key暂存到一个池子中，持续随机取出一批key，并与之前池子中的key比较，再筛选一个最少拜访的key。以此循环，直到内存降到maxmemory之下。
假如运用的是allkeys-random或volatile-random战略，那么就会快许多，由于是随机筛选，那么就少了比较key拜访频率时刻的耗费了，随机拿出一批key后直接筛选即可，因而这个战略要比上面的LRU战略履行快一些。

但以上这些筛选战略的逻辑都是在拜访Redis时，真实指令履行之前履行的，也便是它会影响真实需求履行的指令。

别的，假如此刻Redis实例中有存储大key，那么在筛选大key开释内存时，这个耗时会愈加久，推迟更大

AOF耐久化

同步耐久化

当 Redis 直接记载 AOF 日志时，假如有许多的写操作，而且装备为同步耐久化

appendfsync always

即每次发生数据改变会被当即记载到磁盘，而且Always写回战略是由主进程履行的，而写磁盘比较耗时，功用较差，所以有时会堵塞主线程。

AOF重写

fork 出一便条线程来将文件重写，在履行 BGREWRITEAOF 指令时，Redis 服务器会保护一个 AOF 重写缓冲区，该缓冲区会在子线程创立新 AOF 文件期间，记载服务器履行的一切写指令。
当子线程完结创立新 AOF 文件的作业之后，服务器会将重写缓冲区中的一切内容追加到新 AOF 文件的结尾，使得新的 AOF 文件保存的数据库状况与现有的数据库状况共同。
最终，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完结 AOF 文件重写操作。

堵塞便是呈现在第2步的进程中，将缓冲区中新数据写到新文件的进程中会发生堵塞。

fork耗时

生成RDB和AOF重写都需求父进程fork出一个子进程进行数据的耐久化，在fork履行进程中，父进程需求仿制内存页表给子进程，假如整个实例内存占用很大，那么需求仿制的内存页表会比较耗时，此进程会耗费许多的CPU资源，在完结fork之前，整个实例会被堵塞住，无法处理任何恳求，假如此刻CPU资源严峻，那么fork的时刻会更长，乃至到达秒级。这会严峻影响Redis的功用。

Redis 在进行 RDB 快照的时分，会调用体系函数 fork() ，创立一个子线程来完结临时文件的写入，而触发条件正是装备文件中的 save 装备。当到达装备时，就会触发 bgsave 指令创立快照，这种方法是不会堵塞主线程的，而手动履行 save 指令会在主线程中履行，堵塞主线程。

除了由于备份的原因生成RDB之外，在【主从仿制】第一次树立衔接全量仿制时，主节点也会生成RDB文件给从节点进行一次全量同步，这时也会对Redis发生功用影响。

要想防止这种状况，需求规划好数据备份的周期，主张在从节点上履行备份，而且最好放在低峰期履行。假如关于丢掉数据不灵敏的事务，那么不主张敞开AOF和AOF重写功用。

集群扩容

Redis 集群能够进行节点的动态扩容缩容，这一进程现在还处于半自动状况，需求人工介入。

在扩缩容的时分，需求进行数据搬迁。而 Redis 为了确保搬迁的共同性，搬迁一切操作都是同步操作。

履行搬迁时，两头的 Redis 均会进入时长不等的堵塞状况，关于小Key，该时刻能够忽略不计，但假如一旦 Key 的内存运用过大，严峻的时分会触发集群内的毛病搬运，形成不必要的切换。

总结

运用复杂度高的指令，履行指令时就会耗时
存储大key：假如一个key写入的数据非常大，Redis在分配内存、删去大key时都会耗时，而且耐久化AOF的写回战略是always时会影响Redis功用
会集过期：Redis的自动过期的守时使命，是在Redis主线程中履行的，最差的状况下会有25ms的堵塞
实例内存到达上限时，筛选战略的逻辑都是在拜访Redis时，真实指令履行之前履行的，也便是它会影响真实需求履行的指令。
fork耗时：生成RDB和AOF重写都需求父进程fork出一个子进程进行数据的耐久化，假如整个实例内存占用很大，那么需求仿制的内存页表会比较耗时

额定总结大key的影响：
假如一个key写入的数据非常大，Redis在分配内存、删去大key时都会耗时。
当实例内存到达上限时，在筛选大key开释内存时，内存筛选战略的耗时会愈加久，推迟更大
AOF耐久化时，运用always机制，这个操作是在主线程中履行的，假如写入是一个大 Key，主线程在履行 fsync() 函数的时分，堵塞的时刻会更久。
生成RDB和AOF重写时会fork出一个子进程进行数据的耐久化，父进程需求仿制内存页表给子进程，假如整个实例内存占用很大，那么需求仿制的内存页表会比较耗时。