Redis高可用到底咋实现的，原理和实践中那些关键点分享

Redis的高可用，说白了就是让Redis服务在出现故障的时候，能不间断或者只中断非常短的时间就快速恢复，保证业务基本不受影响，这就像给Redis上了个“保险”，实现这个目标，主要靠两种主流方案：主从复制加哨兵模式，以及Redis Cluster集群,下面我们就聊聊它们的原理和实践中的关键点。

主从复制 + 哨兵模式：经典组合拳

这个方案可以拆成两部分来看：首先是数据备份,然后是故障自动切换。

主从复制：数据多备几份 原理很简单，一主多从”，你指定一个Redis实例作为“主节点”，它负责处理客户端的读写请求，可以配置多个“从节点”，从节点就像是主节点的跟班，它会实时地、自动地从主节点那里复制数据过来。（来源：Redis官方文档关于复制的说明）这样一来，一份数据就有了好几个副本，即使主节点所在的服务器宕机了，数据还在从节点上存着,不会丢失。

实践中关键点：

• 读写分离：这是一个很重要的实践，因为写操作只在主节点进行，读操作可以分散到各个从节点上，这样可以极大地提升系统的整体读吞吐量，减轻主节点的压力，但要注意，从节点复制数据有微小的延迟,对读数据一致性要求极高的场景需要谨慎。
• 从节点也是后备军：除了分担读压力，从节点核心作用就是“备胎”，一旦主节点挂了,可以从从节点中选出一个新的主节点。
• 配置要点：在主节点的配置文件里设置requirepass密码，并在从节点的配置文件中用masterauth指令配上同样的密码，这是为了保证复制链路的安全，网络稳定性至关重要，不稳定的网络会导致频繁的全量复制,消耗大量带宽和资源。

哨兵模式：自动化的故障转移管家 光有从节点还不够，因为主节点挂了之后，需要有人能自动发现这个情况，然后手动把一个从节点“扶正”成新的主节点，并通知其他从节点和客户端，这个“管家”就是Redis Sentinel（哨兵）。（来源：Redis官方文档关于Sentinel的说明）

哨兵本身是一个或多个独立的进程（建议至少部署3个哨兵实例，形成奇数个，便于投票决策），它不存储数据,只负责监控主从节点的健康状态。

实践中关键点：

• 主观下线和客观下线：这是哨兵工作的核心机制，一个哨兵发现主节点连接不上了，它会先标记为“主观下线”，但这可能只是网络抖动，这个哨兵会询问其他哨兵的意见，当达到一定数量（比如超过半数）的哨兵都认为主节点失联了，才会判定为“客观下线”,这时才会触发故障转移流程。
• 自动选举新主：确认为客观下线后，哨兵们会开会投票，从剩下的从节点中选出一个数据最完整、运行最稳定的，将其升级为新的主节点，然后让其他从节点复制这个新主节点，并更新客户端的配置,告诉它们新的主节点地址。
• 避免单点故障：哨兵自己也不能是单点，必须部署多个（通常是3个或5个），并且分散在不同的物理服务器上,防止一台机器宕机导致哨兵系统瘫痪。

Redis Cluster：去中心化的分布式方案

当数据量非常大，单个主节点内存不够用，或者写操作压力大到一台机器扛不住时，主从+哨兵的方案就有瓶颈了，这时就需要Redis Cluster。（来源：Redis官方文档关于Cluster的说明）

它的原理可以理解为“分片”加“高可用”二合一。

• 数据分片：Redis Cluster把整个数据集自动划分成16384个哈希槽，你可以部署多个主节点（比如3个），每个主节点负责一部分哈希槽，客户端请求时，会根据key计算它属于哪个槽，然后被定向到对应的主节点上处理，这样,数据存储和写压力就自然分摊了。
• 内置高可用：在Redis Cluster里，每个负责槽的主节点都可以配置一个或多个从节点，当某个主节点故障时，Cluster内部会自动触发故障转移，由其从节点接替成为新的主节点,整个过程对客户端是透明的。

实践中关键点：

• 客户端要求高：客户端需要支持Redis Cluster协议，能够缓存槽位映射信息，并在节点变更时进行更新，不像主从+哨兵模式,有时可以用一个代理层来屏蔽复杂性。
• 节点管理：扩容和缩容（增加或减少节点）需要谨慎操作，因为会涉及到哈希槽的重新分配，虽然Redis-trib工具可以辅助，但过程中会有部分请求可能被重定向,需要规划在业务低峰期进行。
• 网络要求更严格：Cluster节点之间通过Gossip协议通信，频繁交换信息以维护集群状态,网络延迟和稳定性对集群的健康影响更大。

总结一下： 选择哪种方案，看你的实际需求，如果数据量不大，追求简单和灵活的读写分离，主从+哨兵是成熟稳定的选择，如果数据量巨大，并发要求高，需要水平扩展，那么直接上Redis Cluster更合适，无论哪种，都要记住：高可用不是100%不中断，而是通过冗余和自动化，将故障影响降到最低，实践中的网络配置、密码安全、监控告警,都是确保高可用能真正生效的关键细节。