当 Redis 发生高延迟时，到底发生了什么

Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快不少。可是 Redis 也会发生延迟时，这是就须要咱们对其产生缘由有深入的了解，以便于快速排查问题，解决 Redis的延迟问题

一条命令执行过程

在本文场景下，延迟 (latency) 是指从客户端发送命令到客户端接收到命令返回值的时间间隔。因此咱们先来看一下 Redis 一条命令执行的步骤，其中每一个步骤出问题均可能致使高延迟。

上图是 Redis 客户端发送一条命令的执行过程示意图，绿色的是执行步骤，而蓝色的则是可能出现的致使高延迟的缘由。

网络链接限制、网络传输速率和CPU性能等是全部服务端均可能产生的性能问题。可是 Redis 有本身独有的可能致使高延迟的问题：命令或者数据结构误用、持久化阻塞和内存交换。

并且更为致命的是，Redis 采用单线程和事件驱动的机制来处理网络请求，分别有对应的链接应答处理器，命令请求处理器和命令回复处理器来处理客户端的网络请求事件，处理完一个事件就继续处理队列中的下一个。一条命令处理出现了高延迟会影响接下来处于排队状态的其余命令。有关 Redis 事件处理机制的能够参考本篇文章。

对于高延迟，Redis 原生提供慢查询统计功能，执行 slowlog get {n} 命令能够获取最近的 n 条慢查询命令，默认对于执行超过10毫秒(可配置)的命令都会记录到一个定长队列中，线上实例建议设置为1毫秒便于及时发现毫秒级以上的命令。

1. # 超过 slowlog-log-slower-than 阈值的命令都会被记录到慢查询队列中
2. # 队列最大长度为 slowlog-max-len
3. slowlog-log-slower-than 10000
4. slowlog-max-len 128

若是命令执行时间在毫秒级，则实例实际OPS只有1000左右。慢查询队列长度默认128，可适当调大。慢查询自己只记录了命令执行时间，不包括数据网络传输时间和命令排队时间，所以客户端发生阻塞异常 后，可能不是当前命令缓慢，而是在等待其余命令执行。须要重点比对异常和慢查询发生的时间点，确认是否有慢查询形成的命令阻塞排队。

slowlog的输出格式以下所示。第一个字段表示该条记录在全部慢日志中的序号，最新的记录被展现在最前面；第二个字段是这条记录被记录时的系统时间，能够用 date 命令来将其转换为友好的格式第三个字段表示这条命令的响应时间，单位为 us (微秒)；第四个字段为对应的 Redis 操做。

1. > slowlog get
2. 1) 1) (integer) 26
3. 2) (integer) 1450253133
4. 3) (integer) 43097
5. 4) 1) "flushdb"

下面咱们就来依次看一下不合理地使用命令或者数据结构、持久化阻塞和内存交换所致使的高延迟问题。

不合理的命令或者数据结构

通常来讲 Redis 执行命令速度都很是快，可是当数据量达到必定级别时，某些命令的执行就会花费大量时间，好比对一个包含上万个元素的 hash 结构执行 hgetall 操做，因为数据量比较大且命令算法复杂度是 O(n)，这条命令执行速度必然很慢。

这个问题就是典型的不合理使用命令和数据结构。对于高并发的场景咱们应该尽可能避免在大对象上执行算法复杂度超过 O(n) 的命令。对于键值较多的 hash 结构可使用 scan 系列命令来逐步遍历，而不是直接使用 hgetall 来所有获取。

Redis 自己提供发现大对象的工具，对应命令：redis-cli-h {ip} -p {port} bigkeys。这条命令会使用 scan 从指定的 Redis DB 中持续采样，实时输出当时获得的 value 占用空间最大的 key 值，并在最后给出各类数据结构的 biggest key 的总结报告。

1. > redis-cli -h host -p 12345 --bigkeys
3. # Scanning the entire keyspace to find biggest keys as well as
4. # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
5. # per 100 SCAN commands (not usually needed).
7. [00.00%] Biggest hash found so far 'idx:user' with 1 fields
8. [00.00%] Biggest hash found so far 'idx:product' with 3 fields
9. [00.00%] Biggest hash found so far 'idx:order' with 14 fields
10. [02.29%] Biggest hash found so far 'idx:fund' with 16 fields
11. [02.29%] Biggest hash found so far 'idx:pay' with 69 fields
12. [04.45%] Biggest set found so far 'indexed_word_set' with 1482 members
13. [05.93%] Biggest hash found so far 'idx:address' with 159 fields
14. [11.79%] Biggest hash found so far 'idx:reply' with 196 fields
16. -------- summary -------
18. Sampled 1484 keys in the keyspace!
19. Total key length in bytes is 13488 (avg len 9.09)
21. Biggest set found 'indexed_word_set' has 1482 members
22. Biggest hash found 'idx:的' has 196 fields
24. 0 strings with 0 bytes (00.00% of keys, avg size 0.00)
25. 0 lists with 0 items (00.00% of keys, avg size 0.00)
26. 2 sets with 1710 members (00.13% of keys, avg size 855.00)
27. 1482 hashs with 6731 fields (99.87% of keys, avg size 4.54)
28. 0 zsets with 0 members (00.00% of keys, avg size 0.00)

持久化阻塞

对于开启了持久化功能的Redis节点，须要排查是不是持久化致使的阻 塞。持久化引发主线程阻塞的操做主要有：fork 阻塞、AOF刷盘阻塞。

fork 操做发生在 RDB 和 AOF 重写时，Redis 主线程调用 fork 操做产生共享内存的子进程，由子进程完成对应的持久化工做。若是 fork 操做自己耗时过长，必然会致使主线程的阻塞。

 

Redis 执行 fork 操做产生的子进程内存占用量表现为与父进程相同，理论上须要一倍的物理内存来完成相应的操做。可是 Linux 具备写时复制技术 (copy-on-write)，父子进程会共享相同的物理内存页，当父进程处理写请求时会对须要修改的页复制出一份副本完成写操做，而子进程依然读取 fork 时整个父进程的内存快照。因此，通常来讲，fork 不会消耗过多时间。

能够执行 info stats命令获取到 latestforkusec 指标，表示 Redis 最近一次 fork 操做耗时，若是耗时很大，好比超过1秒，则须要作出优化调整。

1. > redis-cli -c -p 7000 info | grep -w latest_fork_usec
2. latest_fork_usec:315

当咱们开启AOF持久化功能时，文件刷盘的方式通常采用每秒一次，后 台线程每秒对AOF文件作 fsync 操做。当硬盘压力过大时，fsync 操做须要等待，直到写入完成。若是主线程发现距离上一次的 fsync 成功超过2秒，为了数据安全性它会阻塞直到后台线程执行 fsync 操做完成。这种阻塞行为主要是硬盘压力引发，能够查看 Redis日志识别出这种状况，当发生这种阻塞行为时，会打印以下日志：

1. Asynchronous AOF fsync is taking too long (disk is busy). \
2. Writing the AOF buffer without waiting for fsync to complete, \
3. this may slow down Redis.

也能够查看 info persistence 统计中的 aofdelayedfsync 指标，每次发生 fdatasync 阻塞主线程时会累加。

1. >info persistence
2. loading:0
3. aof_pending_bio_fsync:0
4. aof_delayed_fsync:0

内存交换

内存交换（swap）对于 Redis 来讲是很是致命的，Redis 保证高性能的一个重要前提是全部的数据在内存中。若是操做系统把 Redis 使用的部份内存换出到硬盘，因为内存与硬盘读写速度差几个数量级，会致使发生交换后的 Redis 性能急剧降低。识别 Redis 内存交换的检查方法以下：

1. >redis-cli -p 6383 info server | grep process_id # 查询 redis 进程号
2. >cat /proc/4476/smaps | grep Swap # 查询内存交换大小
3. Swap: 0 kB
4. Swap: 4 kB
5. Swap: 0 kB
6. Swap: 0 kB

若是交换量都是0KB或者个别的是4KB，则是正常现象，说明Redis进程内存没有被交换。

有不少方法能够避免内存交换的发生。好比说：

• 保证机器充足的可用内存
• 确保全部Redis实例设置最大可用内存(maxmemory)，防止极端状况下 Redis 内存不可控的增加。
• 下降系统使用swap优先级，如 echo10>/proc/sys/vm/swappiness。

参考

• https://redis.io/topics/latency