Redis线上重启怎么做到零停机，实际操作中那些坑和经验分享

Redis线上重启怎么做到零停机：核心思路与步骤

想做到Redis重启时业务基本无感知，核心思路就一句话：让客户端几乎感觉不到连接被中断，或者即使有短暂中断也能自动恢复，数据不能丢。 直接停机重启是行不行的，因为那会导致所有正在进行的请求失败，数据也可能丢失,下面说具体怎么做。

第一步：最重要的前提，开启持久化，确保数据安全

这是底线，如果数据丢了，什么零停机都是空谈，你必须确保在重启前，Redis内存中的数据已经稳妥地保存到了磁盘上,主要用两种方式：

1. RDB快照：在某个时间点创建一个完整的数据备份，重启前，最好手动触发一次BGSAVE命令，生成一个最新的RDB文件,这样可以减少重启后从节点同步的数据量。
2. AOF日志：记录每一个写操作，建议至少使用appendfsync everysec配置，平衡性能和数据安全，在重启前，可以执行BGREWRITEAOF命令重写AOF日志，让它更紧凑,加快重启时的加载速度。

经验分享：生产环境强烈建议RDB和AOF同时开启，RDB用于快速恢复和备份，AOF保证更高的数据安全性，重启时，Redis会优先加载AOF文件来恢复数据,因为AOF通常数据更完整。

第二步：搭建主从架构，这是实现零停机的“王牌”

单节点的Redis很难做到完美的零停机，一旦引入一个或多个从节点（slave），操作空间就大得多，最常用的方法就是主从切换。

实际操作流程如下：

1. 准备阶段：确保你的主库（master）至少有一个数据同步正常的从库，执行INFO replication命令，确认从库的state是online，并且lag（延迟）很小（比如0或1）。

2. 平滑摘除旧主库：

   • 关键操作：对即将重启的旧主库执行CLIENT PAUSE命令，比如CLIENT PAUSE 10000（暂停10秒接收新请求），这个命令会暂停所有客户端连接，但已有的命令会继续执行完毕，这给了应用程序一个“缓冲期”，确保在途的请求处理完,并且所有数据都能同步到从库。
   • 等待同步：在暂停期间，观察从库的复制偏移量（master_repl_offset）,确保主从数据完全一致。

3. 进行主从切换：

   • 手动或自动切换：如果你用了Sentinel（哨兵）或Cluster（集群）模式，它们会自动检测主库下线并选举新主库，如果是简单的主从，你需要手动执行命令：先在从库上执行SLAVEOF NO ONE,让它升级为主库。
   • 坑点预警：手动切换时，一定要先摘除旧主，再提升新主,顺序反了可能会导致数据冲突。

4. 通知客户端指向新地址：

   • 这是最大的挑战，切换完成后，应用程序必须连接到新的主库，有几种方式：
     • 最佳实践：使用代理或负载均衡器：比如使用HAProxy、Twemproxy或者Redis Cluster，客户端永远连接代理的VIP（虚拟IP），重启时，你只需要在后台修改代理的配置，将流量指向新的主库，对客户端来说，IP没变，完全无感知,这是最推荐的方式。
     • 次优方案：客户端配置动态发现：如果客户端支持（比如一些优秀的Redis连接池），可以配置一个配置中心（如ZooKeeper, Consul, Nacos），当主库变更时，更新配置中心,客户端监听变化并自动切换连接。
     • 最原始但常用：修改配置重启应用：这是下策，但很多公司还在用，就是修改所有应用服务器的Redis连接配置，然后分批重启应用，这会导致应用层面有停机，并不是真正的“零停机”。

5. 重启旧主库并降级为从库：

   • 现在可以安全地重启那个旧的主库了，因为数据已经通过持久化文件保存，或者可以从新的主库重新同步,所以重启是安全的。
   • 重启后，将它配置为新区主库的从库（执行SLAVEOF <new_master_ip> <new_master_port>），让它重新同步数据,作为备用节点。

第三步：重启操作中的那些“坑”和经验

1. 最大最深的坑：持久化配置不当导致数据丢失或重启失败。

   • 场景：没开AOF，RDB最后一次保存是几小时前,重启直接丢失大量数据。
   • 场景：AOF文件损坏，Redis启动时会拒绝加载损坏的AOF文件，导致服务无法启动。经验：定期用redis-check-aof工具检查AOF文件,并有完整的RDB备份作为兜底。

2. 坑：主从复制延迟太大。

   • 如果在从库数据还没同步完的时候就强行切换，会丢失一部分数据。经验：重启维护窗口期，务必通过INFO replication确认主从延迟为0，或者使用WAIT命令强制等待N个从库同步完成。

3. 坑：CLIENT PAUSE时间设置太短。

   • 如果10秒内，旧主库还有大量写请求没同步到从库，时间就到了，切换还是会丢数据。经验：根据业务高峰期流量评估一个保守的时间，比如30秒或更长,同时监控复制偏移量才是最准的。

4. 坑：内存不足，重启后数据加载失败。

   • Redis重启加载RDB或AOF文件时，所需内存可能比运行时还高（因为要构造内部数据结构），如果系统内存刚好被占满，会导致加载失败。经验：确保服务器有足够的空闲内存（比如比Redis最大使用内存多20%-30%）。

5. 坑：客户端连接池的“僵尸连接”。

   • 即使你完美切换了Redis服务器，客户端的连接池里可能还保持着对旧主库的无效长连接，这些连接会持续报错，直到超时或被清除。经验：在切换后，主动在客户端触发一下连接池的刷新或重启机制,或者使用支持自动发现故障节点的智能连接池。

6. 经验：一定要在业务低峰期操作。

   • 任何高可用方案都有风险，选择流量最小的时候进行，能把影响降到最低。提前做好演练，在测试环境模拟整个流程,熟悉每一个命令和可能的现象。

总结一下，Redis零停机重启不是一个单一命令能搞定的事，它是一个组合拳：持久化保证数据不丢 + 主从架构提供冗余 + 代理或动态发现屏蔽底层变更 + 谨慎的操作流程和充分的验证，缺了任何一环，都可能踩坑，在实际操作中，最稳妥的方式就是通过代理层来做，这是对业务侵入最小、效果最好的方案。