技术分享 | sentinel 架构下的切换逻辑

作者：岳明强

爱可生北京分公司 DBA 团队成员，负责数据库管理平台的运维和 MySQL 问题处理。擅长对 MySQL 的故障定位。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

什么是 sentinel

Redis 作为最受欢迎的 NoSQL 数据库之一，主要特点为：高性能、高可用、高可扩展和具有丰富的数据结构。其中 sentinel 作为 Redis 的高可用实现架构，能够实现主库发生故障后，自动切换到从库上。那么它的原理是什么呢，接下来我们进行揭晓。

sentinel 之间的相互发现

当我们配置 sentinel 集群的时候，每个 sentinel 只配置和主库的连接，但是 sentinel 之间没有相互配置，那么sentinel 之间怎么识别呢？

每个 sentinel 定时（2s）向集群下主从的 Pub/Sub 的_sentinel_:hello 发送消息，将自己的信息写入，同时进行订阅。当检测到新的 sentinel 时就会立即加入到集群中。

判断主节点下线

正常情况下需要3个及以上奇数个的 sentinel 节点组成集群，sentinel 每隔 SENTINEL_PING_PERIOD(1000ms)时间给主库发送一次 PING 命令

当在 is-master-down-after-milliseconds 时间内没有返回一次结果，那么就将状态设置为 s_down（主观下线），这时候能做切换吗？

答案是不能，因为这只是单节点 sentinel 对 redis 的监控，还需要结合其他 sentinel 节点的探测结果，再判断是否进行切换。

当判断主观下线后，会向其他 sentinel 节点发送 SENTINEL is-master-down-by-addr，当获得至少超过 quorum 的 sentinel 节点支持后，那么将状态设置为 o_down (客观下线)，判断节点下线。

选择新节点

当判断主节点下线后，会根据一定的条件判断剩下节点能否选举为主：

1、从库状态正常。带有 S_DOWN 、O_DOWN 和 DISCONNECTED 状态的从服务器不会被选中

2、从库响应正常。PING 超过5s，INFO 超过3倍的 info_refresh 的时间内没有收到回复的从服务器不会被选中

3、复制相对正常的从库。主从连接中断时间不能过长

4、优先级不能为0

对从库按照下面内容进行排序，选择最佳的实例提升为主库

优先级小的从库 > 复制偏移量较大的从库 > runid 较小的从库 > 执行较多命令的从库

神奇的Gossip协议

Redis 状态从 S_DOWN 到 O_DOWN 的状态转变，是由 sentinel 之间协商解决的，那他们是直接把信息直接广播给其他节点吗？

有一句话叫谣言是世界上传播最快的病毒，那么谣言是怎么病毒性传播的呢。譬如某男性艺人塌房，从极个别圈子到普罗大众之间的距离，可能也就几天时间。这当然不是那极少数的人给所有人公布：我有谁谁的黑料。而是少数人先给身边的人散播，然后身边的人再加一些猜测，散布给更多的人，直到市面上某艺人的黑料满天飞。

sentinel 就是采取的这样的方式进行通讯，叫 Gossip 协议。与上述不同的是中间所有的信息是真实的，每个节点都将自己节点的信息随机发送给一些节点，第二波的时候，会将自己掌握的信息再随机发给其他节点，一波一波的散播，直到所有的节点数据一致。Gossip 协议在 Redis 上另一个用途是做 Redis Cluster 的内部通讯。Redis Cluster 的分片数量如果太多，那么实例间的信息的传递也就很费劲，采取了 Gossip 协议，能够保证无论加入多少节点，所有节点之间的通讯压力都不大。

结语

本文章主要是对 Redis sentinel 的概念性的东西做了一个解释，包含判断方式、选举方式、切换流程、通讯手段等。大家如果想了解更多，请关注我们公众号里 Redis 的后续文章。