Redis集群主备切换详解，掌握技巧还是仅需了解？
对于大多数应用开发者来说，了解Redis主备切换的基本原理和监控手段就足够了，不需要深入掌握手动切换的复杂技巧，因为通常有自动化工具负责；但如果你是运维人员或负责系统稳定性，那么掌握一些关键技巧和排查方法则是必要的。
什么是主备切换？
你可以把Redis集群想象成一个团队，其中有一个主节点（Master）负责处理所有写操作和主要的读操作，而一个或多个备节点（Slave）则同步主节点的数据，作为备份。当主节点因为故障、维护或网络问题无法工作时，系统会自动或手动将其中一个备节点提升为新的主节点，这个过程就是主备切换。目的是保证服务不中断，数据不丢失。
自动切换是如何工作的？
在官方推荐的Redis Sentinel（哨兵）或Redis Cluster模式下，切换通常是自动的。Sentinel会持续监控主节点和备节点的健康状态。如果它发现主节点不可达（比如心跳检测失败），多个Sentinel会进行协商，确认主节点确实故障了，然后选举出一个领头Sentinel。这个领头Sentinel会从健康的备节点中选出一个最适合的（例如数据最新的那个），向其发送“SLAVEOF NO ONE”命令，使其变成新的主节点。接着，它会通知其他备节点去复制这个新的主节点，并更新客户端配置，让客户端连接到新的主节点。整个过程对应用是透明的，但可能会有几秒到几十秒的短暂服务不可用或延迟。
什么时候需要手动干预？
尽管自动切换很智能，但在某些场景下，手动操作或深入了解技巧很重要。比如，自动化工具可能误判（网络抖动导致主节点被误认为下线），此时你需要阻止不必要的切换，避免脑裂（两个主节点同时存在）。又或者，在计划内维护时（如升级主节点服务器），你希望手动、优雅地进行切换，以最小化影响。此外，当自动切换失败后（例如备节点数据太旧），也需要人工介入排查和恢复。
开发者需要掌握的关键点
作为开发者，你不需要去记忆具体的命令行，但应该理解这些概念，以便更好地设计和应对：
1. 客户端重连：你的应用代码应该能处理连接中断，并支持重新获取新的主节点地址。很多客户端库（如Jedis、Lettuce）集成了Sentinel或Cluster发现机制，会自动重连。
2. 数据一致性窗口：切换期间，可能有少量最新写入的数据尚未同步到备节点，新主节点可能缺失这部分数据。如果你的应用对数据一致性要求极高，需要了解这个风险。
3. 监控告警：确保团队有监控，能及时知道发生了主备切换事件，并检查切换后集群是否健康。
运维人员需要了解的技巧
如果你是负责运维的，以下技巧有助于你更从容：
1. 强制故障转移：在Sentinel模式下，你可以通过命令 `sentinel failover
2. 优先级设置：你可以给不同的备节点设置不同的优先级（在配置文件中），让Sentinel优先选择优先级高的节点作为新主。
3. 处理旧主节点恢复：当旧的主节点恢复后，它会作为备节点重新加入集群，并同步新主的数据。你需要确认其数据同步状态是否正常。
4. 网络分区处理：在网络分裂（脑裂）时，可能需要手动关闭其中一个分区的主节点，以保证数据一致性。
FAQ
问：主备切换期间，我的应用会报错吗？该如何处理？
答：可能会遇到短暂的连接错误或超时。处理方式是确保你的客户端库支持自动发现和重试机制，并在代码中做好通用的异常处理（如重试、降级），避免因短时故障导致应用崩溃。
问：如何判断一次主备切换是成功的？
答：成功的标志包括：新的主节点开始正常接受读写请求；其他备节点正确复制新主节点；客户端连接成功迁移到新主；监控显示集群状态稳定，没有持续的告警。你可以通过 `redis-cli` 连接Sentinel或用 `CLUSTER NODES` 命令（对于Cluster模式）来查看节点角色变化。
问：如果切换后数据不一致怎么办？
答：首先检查备节点的复制偏移量是否追上了新主节点。如果差距很大，可能存在数据丢失风险。这时候需要从备份恢复数据，或者人工核对关键数据。预防重于治疗，确保复制链路稳定并监控复制延迟是关键。
引用来源：本文内容参考了Redis官方文档关于高可用和复制的章节，并结合了常见的运维实践经验。官方文档地址：https://redis.io/topics/replication 和 https://redis.io/topics/sentinel。