Redis 高可用集群原理及选型 —— 主从复制、Sentinel、Cluster

本文介绍了Redis的主从复制模式、Sentinel的监控与故障转移、以及Cluster的负载均衡和在线扩展。这些模式有助于提高可用性，但存在数据一致性不强和单点限制等问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在这里插入图片描述

主从复制模式中包含一个 master 与一个或多个 slave，客户端可对 master 进行读写操作，对 slave 进行读操作，master 写入的数据会以异步的方式实时自动发送给 slave。

slave 启动后，向 master 发送 SYNC 命令，master 接收到 SYNC 命令后通过 bgsave
保存快照，并使用缓冲区记录保存快照这段时间内执行的写命令。
master 将保存的快照文件发送给 slave，并继续记录执行的写命令。
slave 接收到快照文件后，加载快照文件，载入数据。
master 快照发送完后开始向 slave 发送缓冲区的写命令，slave 接收命令并执行，完成复制初始化。
此后，master 每次执行一个写命令都会异步发送给 slave，保持 master 与 slave 之间数据的弱一致性。

在这里插入图片描述

定期（默认10s一次，当 master 被标记为主观下线时，改为1s一次）向 master 和 slave 发送INFO命令。
定期（默认1s一次）向 master、slave 和其他哨兵发送 PING 命令。
如果被 PING 的节点超时未回复，哨兵认为其主观下线。如果下线的是master，哨兵会向其它哨兵发送命令询问它们是否也认为该
master 主观下线，如果达到一定数目（即配置文件中的 quorum）投票，哨兵会认为该 master
已经客观下线，并选举领头的哨兵节点对主从系统发起故障恢复。如果没有足够的 sentinel 节点同意 master 下线或者 master
重新向 sentinel 节点发送的 PING 命令返回有效回复，那么 master 的主观下线状态就会被移除。
领头哨兵从出现故障的 master 的 slave 中挑选一个来当选新的 master。
所有在线的 slave 中选择优先级最高的，优先级可以通过 slave-priority 配置。
如果有多个最高优先级的 slave，则选取复制偏移量最大的当选。
如果以上条件都一样，选取 ID 最小的 slave。

在这里插入图片描述

Cluster 要求至少需要3个 master 才能组成一个集群，同时每个 master 至少需要有一个 slave
节点，各个节点之间保持 TCP 通信，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

集群中每个 Redis 实例都负责接管一部分插槽（slot），总槽数为：16384（2^14），取值范围为：0-16383。
当我们存取 key 的时候，Redis 会根据 CRC16 的算法得出一个结果，然后把结果对16384求余数，这样每个 key
都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
Cluster 模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会主从切换。
集群中当其他主节点 ping
主节点A时，如果半数以上的主节点与主节点A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了。