当前位置：首页 > news >正文

八、Redis的主从原理、哨兵

news 来源：原创 2025/6/27 2:37:37

简介：

想要了解Redis的主从原理，首先得认识一个基本的分布式理论-CAP理论。要理解这个理论，其实也非常简单。

CAP理论

C：Consistency、A：Available、P：Partition tolerance 。这是CAP三个字母的全称。C，一致性，即分布式系统中，两个节点之间的数据要是同步的。 A，可用性，当一个节点服务不可用时，另一个服务可以提供服务。P就是分区多节点服务的能力。

我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务。由此可以看出来，要么AP、要么CP。

一句话概括，CAP要么牺牲一致性，保障可用性，要么牺牲可用性，保证数据的绝对一致。

强一致性和最终一致性

最终一致性：指的是最终结果，各个节点的数据是一致的。但过程中，数据由于更新，节点的数据可能不同。这种场景主要用于对一致性要求不那么高的场景，如聊天等。

强一致性：即各个节点的数据随时随地都是保证一致的。适用于对一致性高的场景，例如股票交易、银行转账等场景。这种场景下，绝不能出现不同交易人员看到不同的股票价格，或者说转账时金额对不上。

Redis就是最终一致性的模型，并不要求数据绝对一致。

主从复制

还记得上一节的AOF日志、RDB快照吗？它们不仅仅用于持久化，还用于主从复制。同样的，增量的主从复制也是通过指令实现的，RDB用于全量的增量复制。

指令实现增量主从复制

当主节点执行写指令时，先将指令写到buffer缓存中，再将指令同步给从节点。这个所谓的buffer缓存是一个固定大小的环形数组，数组满的时候会重新覆盖。缓存的思想在各大中间件都有所体现，例如Kafka、Mysql都有异步刷盘，Redis自身持久化也用了缓存机制。

RDB快照同步

RDB并不仅限于数据持久化，当一个节点刚加入集群，进行主从复制时，该节点会进行一次全量复制，正是主节点bgsave之后，将RDB快照复制给从节点。该过程会大量消耗时间、网络资源。

Sentinel哨兵机制

前面只讲了Redis集群主从复制，如果Redis主节点宕机了，是否有类似于Kafka的Zookeeper一样的机制帮我们主从切换呢？有的，这就是Sentinel哨兵。

如何判定主节点挂了？

类似于Kafka的broker向coordinator发送心跳检测。主节点也需要向哨兵发送“心跳”证明它还活着。具体来讲，哨兵会向所有主从节点发送ping 指令，如果节点没有在规定时间回应，那么哨兵就认为其挂了，需要下线。

高可用场景下，哨兵也需要集群部署。哨兵也集群部署时，当半数以上哨兵认为主节点挂了，那么就会将主节点下线。

选出什么样的主节点？

当主节点挂了的时候，该从那个从节点选成主节点？Kafka是从ISR中选出来主副本。Redis则遵循以下几个规则:

第一轮考察：优先级最高的从节点胜出

Redis 有个叫 slave-priority 配置项，可以给从节点设置优先级。

每一台从节点的服务器配置不一定是相同的，我们可以根据服务器性能配置来设置从节点的优先级。

比如，如果「A 从节点」的物理内存是所有从节点中最大的，那么我们可以把「A 从节点」的优先级设置成最高。这样当哨兵进行第一轮考虑的时候，优先级最高的 A 从节点就会优先胜出，于是就会成为新主节点。

第二轮考察：复制进度最靠前的从节点胜出

如果在第一轮考察中，发现优先级最高的从节点有两个，那么就会进行第二轮考察，比较两个从节点哪个复制进度。

什么是复制进度？主从架构中，主节点会将写操作同步给从节点，在这个过程中，主节点会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置（如下图中的「主服务器已经写入的数据」的位置），而从节点会用 slave_repl_offset 这个值记录当前的复制进度（如下图中的「从服务器要读的位置」的位置）。

如果某个从节点的 slave_repl_offset 最接近 master_repl_offset，说明它的复制进度是最靠前的，于是就可以将它选为新主节点。

#第三轮考察：ID 号小的从节点胜出

如果在第二轮考察中，发现有两个从节点优先级和复制进度都是一样的，那么就会进行第三轮考察，比较两个从节点的 ID 号，ID 号小的从节点胜出。

什么是 ID 号？每个从节点都有一个编号，这个编号就是 ID 号，是用来唯一标识从节点的。

到这里，选主的事情终于结束了。简单给大家总结下：

参考:为什么要有哨兵？ | 小林coding

简介：