前边我们总结了Redis(二)——复制，能够从一定程度上做好备份，扩展读能力（读写分离）。但这种主从复制在出现异常时回带来以下问题：1，一旦主节点出问题，需要手动将一个从节点升级为主节点，手动修改应用方连接信息，手动通过命令其它从节点复制新的主节点，整个过程都需要人工干预。2，主节点的写能力受到单击限制；3，主节点存储能力受到单击限制。而哨兵模式正是解决第1个问题呢。而2、3单机受限问题，只能通过集群的方式进行解决，后边会总结。
上边中问题1，在人工干预中几个棘手的问题：a，判断节点不可达的机制是否健全和标准；2，如果有多个从节点，怎样保证只有一个被晋升为主节点；c，通知客户端新的主节点机制是否健壮。而redis-sentinel正式解决这些问题的。直接一点就是解决了主从复制的高可用问题。
好，接下来我们从：1介绍；2安装部署；3api；4客户端；5实现原理；6开发运维常见问题。几个方面来学习一下。
一，介绍：
上边为其架构图，其实就是从主从复制模式的基础上，添加了sentinel-哨兵节点，来进行监控，以达到出现故障及时处理，保证业务的高可用。看下几个简单名词概念：
| 名词 | 逻辑架构 | 物理架构 |
|---|---|---|
| 主节点-master | Redis主服务DB | 独立的Redis进程 |
| 从节点-slave | Redis从服务DB | 独立的Redis进程 |
| Redis数据节点 | 主节点和从节点 | 主节点和从节点进程 |
| Sentinel节点 | 监控Redis数据节点的节点 | 独立的Sentinel进程 |
Redis Sentinel架构通过以下功能实现了其目标业务高可用：
| 功能 | 说明 |
|---|---|
| 1-监控 | Sentinel节点会定期检查Redis数据节点、其余Sentinel节点是否可达。 |
| 2-通知 | Sentinel节点会将故障转移的结果通知给应用方，使应用方获取最新的master地址。 |
| 3-主节点故障转移 | 实现从节点晋升为主节点并维护后续正确的主从关系。 |
| 4-配置提供者 | client业务连接Sentinel节点集合，获取主节点信息。 |
二，安装和部署：
3个sentinel节点做监控分布，数据节点1主2从。具体步骤看两篇别人写的吧，https://www.cnblogs.com/wxyidea/p/9934608.html，https://blog.csdn.net/qq_18427977/article/details/80930937。
这里我们看一下几个配置优化：
| 命令 | 说明 |
|---|---|
| 1 sentinel monitor <master-name> <ip> <port> <quorum> | 主要是quorum参数用于故障发现判定，至少有quorum个sentinel节点同意，判定才是客观。一般为半数+1,类似我们选举。 |
| 2 sentinel down-after-milliseconds <master> <times> | times（毫秒）数据节点不可达的超时时间，越大表示越宽松，越小表示监控越严格 |
| 3 sentinel parallel-syncs <master-name> <nums> | nums为故障转移后，每次向新的主节点同时发起复制操作的从节点个数。越大并发越高，主节点的网络和磁盘IO开销增大；当为1的时候，轮询进行复制。 |
| 4 sentinel failover-timeout <master-name> <times> | times 故障转移超时时间 |
| 5 sentinel auth-pass <master> <password> | 主节点设置的密码，安全限制 |
| 6 sentinel notification-script <master-name> <script-path> | 方便通过脚本进行邮件或者短信的报警 |
其中Sentinel节点不应该部署在一台物理机上，至少3个且为奇数个sentinel节点，是否要一套sentinel节点集群监控多个主节点，根据实际情况决定。一套sentinel节点方便管理，节约资源，但是出现问题影响范围大；多套sentinel节点恰相反。
三，哨兵模式相关API：这里看这篇文章：https://blog.csdn.net/holdbelief/article/details/79790877，还有我们可以多查看其文档：http://www.redis.cn/topics/sentinel.html
四，client连接sentinel模式：
主要步骤如下：1，遍历sentinel节点集合获取一个可用的sentinel节点；2，通过get-master-addr-by-name获取当前的主节点信息；3，验证当前主节点是否为真正的主节点，防止故障转移期间主节点的变化；4，保持和sentinel节点集合联系，关注主节点的信息变化。
可以看下这篇文章：https://www.cnblogs.com/wangweiNB/p/5620845.html,https://www.cnblogs.com/xujishou/p/6511111.html
五，实现原理：
| 功能 | 说明 |
|---|---|
| 1 Redis Sentinel的三个定时任务 | a，每隔10秒，每隔Sentinel节点会向主、从节点发送info命令获取最新的拓扑结构。 b，每隔2秒，每隔Sentinel节点会向redis数据节点的_sentinel_:hello频道发送该Sentinel节点对于主节点的判断以及当前Sentinel节点信息。达到1了解其他sentinel节点状态信息；2并交换信息，作为后边客观下线和领导者选举的依据。 c，每隔1秒，每隔sentinel节点会向主、从节点、其余的sentinel节点发送一条ping命令做一次心跳检测。 |
| 2 主观下线vs客观下线 | 主观下线：每隔sentinel发送ping心跳检测，如果超过了down-after-milliseconds，则判断下线，为主观下线，即一家判定之言。 客观下线：当超过<quorum>个数判定为下线时，则为客观的。 |
| 3 领导者sentinel节点选举 | 当做出客观下线时，需要做故障转移，这时需要选举一个领导者进行做具体是事件。大概过程如下： a，每个在线的sentinel节点都有资格成为领导者，并发其它节点发出我要当领导者； b，收到其它节点当领导者的命令，如果没有同意过其它节点，则同意，否则拒绝； c，如果该节点发现自己的票数大于等于max(quorum,num(sentinel)/2+1)，那么他将成为领导者； d，如果此过程没有产生，则进入下一轮选举。 |
| 4 故障转移 | a，在从节点选出一个节点作为新的主节点，选择方法：1，过滤不健康（主观下线、断线）；2，选择slave-priority优先级高的；3，选择复制偏移量大的；4选择runid最小的。 b，sentinel领导者对选出的从节点做slaveof no one 命令，让其成为主节点。 c，sentinel领导者向剩余的从节点发送命令，让它们成为新主节点的从节点。 d，sentinel领导者节点集合将原来的主节点更新为从节点，并保持对其关注。当其恢复后，命令它去复制新的主节点。 |
六，开发运维中的注意点：
1，要善于通过日志分许问题，每个节点的日志，都会将其的各种动作记录下来；
2，节点下线，分临时下线和永久下线，注意各自对应的处理方案；
3， 从节点的添加，节点配置一致性，主节点不可添加；
4，读写分离，发挥从节点的分流作用。
好，今天小结了一下redis哨兵模式的流程方案，是对主从复制的一种高可用解决方案。在数据量不是特别大时，不需要要做数据分布式时，哨兵模式是非常棒的选择。 在这里更多学习其哨兵sentinel节点、数据节点、分离并监控的思想。想想是不是像前边学习rocketMq中的nameServer和broker的关系？
