前言
Go on！ go on！今天来讲下关于上篇文章说的redis的哨兵机制的原理，面试必备～废话不多说，大家请收下～
正文
可用性保证之 Sentinel
Sentinel 原理
如何实现主从的自动切换？我们的思路：
创建一台监控服务器来监控所有 Redis 服务节点的状态，比如，master 节点超过一定时间没有给监控服务器发送心跳报文，就把 master 标记为下线，然后把某一个 slave 变成 master。应用每一次都是从这个监控服务器拿到 master 的地址。
问题是：如果监控服务器本身出问题了怎么办？那我们就拿不到 master 的地址了，应用也没有办法访问。
那我们再创建一个监控服务器，来监控监控服务器……似乎陷入死循环了，这个问题怎么解决？这个问题先放着。
Redis 的 Sentinel 就是这种思路：通过运行监控服务器来保证服务的可用性。
从Redis2.8 版本起，提供了一个稳定版本的 Sentinel（哨兵），用来解决高可用的问题。它是一个特殊状态的 redis 实例。
我们会启动一个或者多个 Sentinel 的服务（通过 src/redis-sentinel），它本质上只是一个运行在特殊模式之下的 Redis，Sentinel 通过 info 命令得到被监听 Redis 机器的master，slave 等信息。
为了保证监控服务器的可用性，我们会对 Sentinel 做集群的部署。 Sentinel 既监控所有的 Redis 服务，Sentinel 之间也相互监控。
注意：Sentinel 本身没有主从之分，只有 Redis 服务节点有主从之分。 概念梳理：master，slave（redis group），sentinel，sentinel 集合
服务下线
Sentinel 默认以每秒钟 1 次的频率向 Redis 服务节点发送 PING 命令。如果在 down-after-milliseconds 内都没有收到有效回复，Sentinel 会将该服务器标记为下线（主观下线）。
#sentinel.conf
sentinel down-after-milliseconds <master-name> <milliseconds>
这个时候 Sentinel 节点会继续询问其他的 Sentinel 节点，确认这个节点是否下线，如果多数 Sentinel 节点都认为 master 下线，master 才真正确认被下线（客观下线），这个时候就需要重新选举 master。
故障转移
如果 master 被标记为下线，就会开始故障转移流程。
既然有这么多的 Sentinel 节点，由谁来做故障转移的事情呢？
故障转移流程的第一步就是在 Sentinel 集群选择一个 Leader，由 Leader 完成故障转移流程。 Sentinle 通过 Raft 算法，实现 Sentinel 选举。
Ratf 算法
在分布式存储系统中，通常通过维护多个副本来提高系统的可用性，那么多个节点之间必须要面对数据一致性的问题。Raft 的目的就是通过复制的方式，使所有节点达成一致，但是这么多节点，以哪个节点的数据为准呢？所以必须选出一个 Leader。
大体上有两个步骤：领导选举，数据复制。
Raft 是一个共识算法（consensus algorithm）。比如比特币之类的加密货币，就需要共识算法。Spring Cloud 的注册中心解决方案 Consul 也用到了 Raft 协议。
Raft 的核心思想：先到先得，少数服从多数。
总结：
Sentinle 的 Raft 算法和 Raft 论文略有不同。
- master 客观下线触发选举，而不是过了 election timeout 时间开始选举。
- Leader 并不会把自己成为 Leader 的消息发给其他 Sentinel。其他 Sentinel 等待 Leader 从 slave 选出 master 后，检测到新的 master 正常工作后，就会去掉客观下线的标识，从而不需要进入故障转移流程。
故障转移
问题：怎么让一个原来的 slave 节点成为主节点？
- 选出 Sentinel Leader 之后，由 Sentinel Leader 向某个节点发送 slaveof no one 命令，让它成为独立节点。
- 然后向其他节点发送 slaveof x.x.x.x xxxx（本机服务），让它们成为这个节点的子节点，故障转移完成。
问题：这么多从节点，选谁成为主节点？
关于从节点选举，一共有四个因素影响选举的结果，分别是断开连接时长、优先级排序、复制数量、进程 id。
如果与哨兵连接断开的比较久，超过了某个阈值，就直接失去了选举权。
如果拥有选举权，那就看谁的优先级高，这个在配置文件里可以设置（replica-priority 100），数值越小优先级越高。
如果优先级相同，就看谁从 master 中复制的数据最多（复制偏移量最大），选最多的那个，如果复制数量也相同，就选择进程 id 最小的那个。
Sentinel 的功能总结
- Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.
(监控：Sentinel 会不断检查主服务器和从服务器是否正常运行。) - Notification. Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.
(通知：如果某一个被监控的实例出现问题，Sentinel 可以通过 API 发出通知。) - Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
(自动故障转移（failover）：如果主服务器发生故障，Sentinel 可以启动故障转移过程。把某台服务器升级为主服务器，并发出通知。) - Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
(配置管理：客户端连接到 Sentinel，获取当前的 Redis 主服务器的地址。)
By the way
有问题？可以给我留言或私聊 有收获？那就顺手点个赞呗~ 想找工作机会也可以联系我噢～
当然，也可以到我的公众号下「6曦轩」，
回复“学习”，即可领取一份 【Java工程师进阶架构师的视频教程】~
回复“面试”，可以获得： 【本人呕心沥血整理的 Java 面试题】
回复“MySQL脑图”，可以获得 【MySQL 知识点梳理高清脑图】
还有【阿里云】【腾讯云】的购买优惠噢~具体请联系我
曦轩我是科班出身的程序员，php，Android以及硬件方面都做过，不过最后还是选择专注于做 Java，所以有啥问题可以到公众号提问讨论（技术情感倾诉都可以哈哈哈），看到的话会尽快回复，希望可以跟大家共同学习进步，关于服务端架构，Java 核心知识解析，职业生涯，面试总结等文章会不定期坚持推送输出，欢迎大家关注~~~
