高可用（High Availability）,是分布式架构中应该考虑的，如果我们系统可以一直毫无间断的提供服务，我们我们就说系统的可用性是100%，有些公司给的目标是4个9，也就是99.99%的时间内必须是可用的，换算下来，一年不可用的时间不能超过8.76小时。

但是我们知道，无论是人还是机器，都是有可能出错的，出错了怎么办？如何快速的补救。这里不得不提，单点是系统高可用的最大敌人，高可用，一般以为着集群，或者冗余，一个单点的系统，挂了就是真的挂了，但是一个高可用的系统，一台机器挂了，一般会有其他的机器顶上。

所以，redis也不例外，redis要想更好地服务，就要考虑实现高可用。

1.2 redis高可用思路

前面说过主从架构，现在Redis高可用主要涉及到的是Redis Sentinel，也就是哨兵机制，使用哨兵机制可以在部署一套redis的情况下，没有人为干预情况去应对各种失败的意外情况。

哨兵之所以能够成为一种高可用的解决方案，原因：sentinel系统（一个或者多个实例）可以监视多个master服务器以及master服务器下的所有从服务器，并且通过一定机制检测master node是否故障，故障情况通过投票选举，选出一台slave升级为master node，正常工作下去。

当然了，sentinel是为了高可用性设计得，它要是挂了怎么办，所以它就应该设计成为分布式系统，就算有些sentinel挂了，这个集群也是可以正常工作的，涉及到投票选举。sentinel也会出现误判的时候，所以在判断一个redis是不是可用的时候，需要多个人判断，能够减少判断错误的概率。
当master挂掉的时候，会停止复制

一个slave会被选举出来充当master

另一个master要是恢复的话，会直接挂到最新的master下面，成为一个slave节点。

2、哨兵系统

哨兵节点：哨兵系统由一个或者多个哨兵组成，是特殊的redis节点，不存储数据。其本质上也是redis节点。
每一个哨兵只需要配置监控主节点，可以通过依赖关系自动发现其他节点，和其他的哨兵节点的发现和通信依赖于发布订阅模式。
哨兵不仅仅可以监控一个主节点，而且可以监控多个主节点，这个配置好即可。

哨兵主要有以下功能：

• 监控：不断检测主从服务器是否正常在工作中
• 通知：可以通过api来通知管理员或者其他应用程序，告知我们redis出现了问题。
• 自动故障转移：如果sentinel系统判断出master down掉了，就是不可用了，就会执行故障转移过程，通过投票选举把slave节点提升成为master节点，其他slave节点成为新master节点的从节点。
• 提供配置：客户端连接sentinels，查询主节点的时候，提供最新的master的地址。

之所以使用到哨兵，主要有两种情况：

• slave node 宕机，这个重启后会自动加入主从架构中，自动完成数据同步，redis2.8之前版本是全量复制，之后的版本是增量复制。
• master node 宕机，会先断开master和slave的复制，选举出一个slave，执行SLAVEOF NO ONE,提升成为master节点，之前的master节点重启之后，会执行slaveof命令，设置成为新master的slave节点，同步数据。

哨兵平时做的事情：

• 每10秒向主节点和从节点发送命令获取info信息，也就是整个redis的结构，我们在配置文件其实只是配置了master节点，可以通过向master发送info信息，就可以找到slave，也就可以向slave也发送信息了。
• 每个哨兵每隔两秒钟，就会向订阅消息的信息频道发送信息，其他节点也会订阅这个BUS,发送的信息一般是关于自己对各个节点的判断以及当前哨兵节点的消息。这种模式的好处是减少资源的消耗。
• 每隔一秒钟，哨兵会向主节点和从节点以及其他的哨兵发送一次ping，做心跳检查，看看这些是都正常活着的状态。

小结一下，哨兵机制主要是信不过主从架构，如果一个挂了，总有人要选出新的，哨兵就专门做这个，我就看着你们，你们好好玩，玩不好，就给你们换个老大。一个哨兵不可靠，那就多个哨兵，我们公平一点，选举，旨在将故障的影响降低。
此文章仅代表自己（本菜鸟）学习积累记录，或者学习笔记，如有侵权，请联系作者删除。人无完人，文章也一样，文笔稚嫩，在下不才，勿喷，如果有错误之处，还望指出，感激不尽~

技术之路不在一时，山高水长，纵使缓慢，驰而不息。