Redis积压缓冲区问题怎么管，优化方案聊聊那些实操经验和思路

关于Redis的积压缓冲区问题，说白了就是Redis处理不过来数据了，生产者（比如你的应用程序）往Redis里塞数据的速度，超过了消费者（比如另一个应用来读取处理数据，或者Redis主实例向从实例同步数据）处理数据的速度，这个来不及处理的数据，就会在一个叫“积压缓冲区”的地方堆着，这个缓冲区大小是有限的，一旦堆满了，新来的数据就会把最旧的数据挤掉,这就会引发一系列问题。

这个问题最典型的场景就是主从复制。 当你的Redis是主从架构时，主节点会把所有写命令都记录在积压缓冲区里，从节点会从这里获取自己断线期间错过的数据来保持同步，如果从节点断开连接的时间太长，或者主节点写入的流量突然暴增，导致缓冲区满了，那么从节点再连上来的时候，就会发现缓冲区里它需要的那部分旧数据已经被覆盖了，这时，从节点就无法进行增量同步了，只能向主节点发起一次全量同步，全量同步相当于把主节点整个内存数据做个快照（RDB）传过去，这对主节点的CPU、内存、网络带宽都是巨大的开销,很可能引发服务雪崩。

管理积压缓冲区的核心思路就两点：一是防止它被写满，二是万一被写满了要有兜底方案，避免服务彻底不可用。

下面聊聊一些实操经验和优化思路,我尽量用大白话说。

第一，也是最根本的：监控和预警。 你不能等问题发生了才知道缓冲区满了，必须提前设置监控,监控什么呢？

1. 监控积压缓冲区的大小和使用率：比如你设置的缓冲区大小是100MB，你要看它平时用了多少，是不是有持续增长的趋势，一旦使用率超过80%,就要发出警告。
2. 监控主从复制的偏移量：主节点会记录自己写了多少数据（主节点偏移量），从节点会记录自己同步了多少（从节点偏移量），这两个偏移量的差值，就是积压缓冲区里还没被从节点消费的数据量，这个差值必须时刻小于你的缓冲区总大小，这个指标比单纯看缓冲区使用率更直观，是监控的重中之重。 这些监控数据可以通过Redis的INFO replication命令获取，然后接入到你的Zabbix、Prometheus等监控系统里。

第二，合理设置缓冲区大小。 Redis积压缓冲区的大小是通过配置项repl-backlog-size来设置的，默认是1MB，这个值在今天看来通常太小了，完全不够用，那设多大合适呢？这里有个经验性的思路（来源网络上的实践经验总结）： 你需要估算一个“安全窗口”，你评估你的从实例最多可能因为网络抖动或重启需要中断连接10秒钟，你就需要计算你的主实例在这10秒内大概会产生多少写入量。 假设你的主实例高峰期的写入速率是每秒10MB（可以通过监控历史数据得到），那么10秒就是100MB，为了留有余地，你可能会把repl-backlog-size设置为200MB甚至更大。 设置大一点的好处是，即使从实例挂了几分钟，也能从缓冲区恢复，避免了昂贵的全量同步，这个缓冲区是预分配的内存，设得太大也会浪费内存，需要根据你的实际情况做个权衡,一般生产环境建议设置为百MB级别起步。

第三，控制写入流量，避免尖峰。 缓冲区被写满，直接原因就是写入太快，除了业务本身的高峰期,有时候一些不当操作也会引发流量尖峰，

• 避免一次性加载大量热数据：如果要缓存一批数据，不要用循环一条条set，应该使用pipeline管道功能，或者使用MSET命令批量设置，减少网络往返次数,也能平滑写入速度。
• * keys 这样的危险命令**：在生产环境绝对不要用，它会遍历所有键，如果键很多，会导致Redis短暂卡顿，可能加剧复制延迟。 控制好源头的水流速度，池子（缓冲区）才不容易满。

第四，优化主从复制的环境和配置。

1. 保证网络质量：主从节点之间的网络必须低延迟、高带宽，如果网络本身不稳定，频繁丢包重传，从节点就会不断断线重连,很容易就导致复制偏移量差距拉大。
2. 使用更快的磁盘：如果从节点需要做全量同步，主节点会生成RDB文件，如果主节点用的磁盘是机械硬盘，写RDB会非常慢，这会长时间阻塞主节点,使用SSD硬盘可以显著改善这个问题。
3. 考虑使用链式复制：当你有多个从节点时，如果都挂载在主节点上，主节点的复制压力会很大，可以让一部分从节点不是直接连接主节点，而是连接一个从节点（这个从节点就变成了它下级的主节点），形成一种链式结构,来分担主节点的复制压力。

第五，做好最坏的打算：兜底和容灾。 即使做了所有优化，也不能保证100%不出问题，你要想好，万一真的发生了因为积压缓冲区不足导致的从节点全量同步,该怎么办？

1. 错峰操作：如果可能,尽量在业务低峰期进行从节点的重启或维护操作。
2. 设置合理的超时参数：repl-timeout参数要设置合理,避免因为网络慢但未断线而误判为超时。
3. 有完整的故障处理预案：当监控发现从节点同步失败时，是自动重启从节点尝试恢复，还是报警让人工介入？人工介入的步骤是什么？这些都要提前想清楚。

管好Redis积压缓冲区，不是一个单一的配置问题，而是一个系统工程,它要求你：

• 心中有数：通过监控了解你的系统常态和瓶颈。
• 手中有粮：根据业务流量预留足够大的缓冲区。
• 脚下有路：优化写入模式和网络环境,从源头减少风险。
• 身后有备：准备好应对极端情况的预案。

把这些点都做到了，虽然不能完全杜绝问题，但至少能把风险控制在可接受的范围，并且出了问题也能快速响应,不至于手忙脚乱。