（转）redis的哨兵机制

为了达到redis的高可用，有两种部署方式：主从复制+哨兵机制；集群模式。哨兵机制是redis2.8开始支持。集群模式是redis3.0开始支持。

主从复制的意义：

主从复制可以把主节点的数据复制给从节点。从节点可以备份主节点的数据，起到主节点down调，顶上来接替主节点工作的作用。也可以起到分担主节点读压力的作用。

没有哨兵机制的时候，主从复制结构部署存在的问题是什么？也可以说redis主节点发生故障如何解决？

如果主节点down调，主从切换需要人工介入。

主从切换步骤为：

1、启用从节点为主节点。命令：slaveof no one

2、旧主节点的其他从节点变成新主节点的从节点。命令：slaveof new master

3、通知应用方redis主节点变成了新主节点。 修改客户端调用的地址并重启客户端。

4、旧主节点变成新主节点的从节点。  命令：slaveof new master





哨兵机制存在的意义：

为了实现redis故障转移的自动化。自动发现，自动转移。不需要人工参与。


哨兵机制是怎样的部署结构？
![图1](https://img-blog.csdn.net/20171229154741129?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbHMxNjQ1/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)



结合上图，主从复制节点是数据节点，哨兵机制部署的节点是监控节点，它们都是redis实例。但是哨兵节点不存储数据，它们监控主从数据节点的状态，若哨兵判定主节点down掉后，就会自动执行上边提到的手工操作的4步。

哨兵节点自动化完成故障转移的过程：
![图2](https://img-blog.csdn.net/20171229162131030?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbHMxNjQ1/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)





哨兵机制是怎样判断主节点down调的？

哨兵机制是建立了多个哨兵节点，它们共同监控数据节点的运行状况。同时哨兵节点之间也互相通信。交换对主从节点的监控状况。下面提到两个概念：

主观下线和客观下线：一个哨兵节点判定主节点down掉是主观下线。只有半数个哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。

基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制，每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时，不会进行主从切换过程。

总结：

肉多嚼不烂，一个一个啃。

能让工具（程序）去做的事情，就不要自己去做。

monitor处处有，自动发现，自动报警，自动解决。流程化的东西就可以考虑让它自动化。

参考书籍：

 《redis开发与运维》

---

以上是转发：
读后个人总结哨兵机制，比如A、B、C 三台机器
A为master BC为从机
其实哨兵的master就是自己玩的数据 set get自己玩不会转发set get请求
从机定时的去主机拉数据同步
如果主机A挂了 BC去ping他的时候ping不通 BC根据权重去客观的选举新的master，这样还有一方面防止主从那样的TPS降低，因为主从复制的时候，又增加了一次网络IO，单个Redis已经很强了，BC相当于热备，A死了BC上去顶住，BC只是不定时的备份A的数据。

以上是个人理解，如有不对，还请指教。

本文转自 李爽11 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/ls1645/article/details/78931605?utm_source=copy