Redis中常见的推迟问题

运用复杂度高的指令

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？

1. 运用 Redis 自带的 --bigkeys 参数来查找：这个指令会扫描(Scan) Redis 中的一切 key ，会对 Redis 的功用有一点影响，最好挑选在从节点上履行该指令，由于主节点上履行时，会堵塞主节点。而且，这种方法只能找出每种数据结构 top 1 bigkey（占用内存最大的 String 数据类型，包括元素最多的复合数据类型）。但是，一个 key 的元素多并不代表占用内存也多，需求咱们依据详细的事务状况来进一步判别。

2. Redis 自带的 SCAN 指令：SCAN 指令能够依照必定的形式和数量回来匹配的 key。获取了 key 之后，能够运用 STRLEN、HLEN、LLEN等指令回来其长度或成员数量。
   

3. 凭借开源东西剖析 RDB 文件：这种计划的条件是Redis 选用的是 RDB 耐久化。网上有现成的东西：

4. • 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重写

1. fork 出一便条线程来将文件重写，在履行 BGREWRITEAOF 指令时，Redis 服务器会保护一个 AOF 重写缓冲区，该缓冲区会在子线程创立新 AOF 文件期间，记载服务器履行的一切写指令。
2. 当子线程完结创立新 AOF 文件的作业之后，服务器会将重写缓冲区中的一切内容追加到新 AOF 文件的结尾，使得新的 AOF 文件保存的数据库状况与现有的数据库状况共同。
3. 最终，服务器用新的 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 的内存运用过大，严峻的时分会触发集群内的毛病搬运，形成不必要的切换。

总结

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

额定总结大key的影响：

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

面试题专栏

Java面试题专栏已上线，欢迎拜访。

• 假如你不知道简历怎样写，简历项目不知道怎样包装；
• 假如简历中有些内容你不知道该不该写上去；
• 假如有些归纳性问题你不知道怎样答；

那么能够私信我，我会尽我所能协助你。