十分有趣的Redis哨兵模式

监控

他的表层体现是：Redis集群之间相互ping/pong，在固定时间内，去对其他的Redis主机进行检查，判断Master或者Slave是否是一个正常状态。

哨兵其实是一个分布式的一个系统，在Redis整个架构上可以开多个这样的一个进程。

每个哨兵向其他的哨兵的Maser或者Slave发送消息ping，默认1秒/次，如果对方没有回应pong的话，会主观认为对方宕机了，然后自己知道后再告诉整个集群，我这里发现了有Redis宕机了，然后整个集群都处于等待的状态，这个时候是不会进行主备切换的

如果多个哨兵发现这一个Redis宕机后就主观的认为这个服务挂掉了，这个时候才进行主备切换。

这里，Redis集群之间的通讯使用了Gossip协议也叫 Epidemic Protocol （流行病协议）

这个协议的特点是：“一传十，十传百.....”,就和新冠状肺炎似的，也有人称其“流言算法”、“疫情传播算法”等。

优势：

可拓展性：

算法复杂度： O(logN) ，每个节点发送固定数量的消息，不关注节点数目，也不关注消息是否被接受，它是个异步的，轻松拓展百万个进程。

容错性：

节点之间的宕机对这整个协议运行没影响

健壮性：

去中心化，所有节点都是平等的，可以随时新增或者移除。

最终一致性：

最后最新的消息会以最快速遍布全部的节点，节点的消息数据最后都是一致

缺点：

消息冗余：

节点之间发送重复的消息，因为他是相邻的节点随机选取发送，可能之前发送了一次，后面还有节点相互ping/pong发送消息

https://zhuanlan.zhihu.com/p/41228196

 

 

提醒

搭建好了哨兵模式，他会调用API告诉后台管理员它监控的这个Redis节点的信息状态打印日志如下：

 

故障迁移

当主备Redis一组节点中，其中主库挂掉了，那么他会从备用库中选一个库作为主库继续保持工作。

1.检查

如果备用节点和主节点的连接超过了cluster-node-timeout * cluster-slave-validity-factor那么就没有资格继承主节点

cluster-slave-validity-factor默认为10

2.选举

首先具备竞争的备用节点会休眠一段时间(500ms)的样子，时间一到这些备用节点就开始抢票，先到先得，这其实和偏移量有光，在主节点和备用节点同步数据的时候会复制偏移量，偏移量越大说明其数据的一致性越高，那么得票的几率越高。

3.投票

只有其他的主节点有投票的权利，每次主节点投票给备用节点的时候，备用节点就和ack消息，然后统计自己的得票情况，如果得票超过了全部主节点一半以上，那么就替换成主节点。

 

这个过程很来源于生活，毕竟这些都是人类设计的，所以很贴近于生活。

我们可以把它变成一个故事：

假如：有一天爸爸在敲代码，突然爸爸(主节点)挂掉了，然后家里三个孩子(备用节点)必须要接替爸爸的活，继续写代码，但是要通过5个叔叔(其他主节点)的投票来决定谁来接替这个活儿，就制定了个规则，谁和爸爸长得最像(偏移量)，而且谁最喜欢写代码(选举)的就给他投票，投票超过一半的人就宣布继承父业。

 

拓展：

各版本之间的区别：https://blog.csdn.net/qq_34206560/article/details/90902924

在Redis3.0后，Redis集群不需要开启哨兵，就可以实现Redis集群之间分片管理，主从复制和故障迁移