哨兵机制
对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。
什么是哨兵机制
sentinel(哨兵机制)：是 Redis 中集群的高可用方式，哨兵节点是特殊的 Redis 服务，不提供读写，主要来监控 Redis 中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。
核心功能就是:监控，选主，通知。
监控：哨兵机制，会周期性的给所有主服务器发出 PING 命令，检测它们是否仍然在线运行，如果在规定的时间内响应了 PING 通知则认为，仍在线运行；如果没有及时回复，则认为服务已经下线了，就会进行切换主库的动作。
选主：当主库挂掉的时候，会从从库中按照既定的规则选出一个新的的主库，
通知：当一个主库被新选出来，会通知其他从库，进行连接，然后进行数据的复制。当客户端试图连接失效的主库时，集群也会向客户端返回新主库的地址，使得集群可以使用新的主库。
如何保证选主的准确性
哨兵会通过 PING 命令检测它和从库，主库之间的连接情况，如果发现响应超时就会认为该服务已经下线了。
当然这会存在误判的情况，如果集群的网络压力比较大，网路堵塞，这时候会存在误判的情况。
如果误判的节点是从节点，影响不会很大，拿掉一个从节点，对整体的服务，影响不大，还是会不间断的对外提供服务。
如果误判的节点是主节点，影响就很大了，主节点被标注下线了，就会触发后续的选主，数据同步，等一连串的动作，这一连串的动作很很消耗性能的。所以对于误判，应该去规避。
如何减少误判呢？
引入哨兵集群，一个哨兵节点可能会进行误判，引入多个少哨兵节点一起做决策，就能减少误判了。
当有多个哨兵节点的时候，大多数哨兵节点认为主库下线了，主库才会真正的被标记为下线了，一般来讲当有 N 个哨兵实例时，最好要有N/2 + 1个实例判断主库下线了，才能最终判定主库的下线状态。当然这个数值在 Redis 中是可以配置的。
如何选主
选举主节点的规则
1、过滤掉已经下线的服务器；
2、过滤掉最近5秒钟没有回复过主节点的 INFO(用于观察服务器的角色) 命令的服务器，保证选中的服务器都是最近成功通过信的；
3、过滤掉和下线主服务器连接超过down-after-milliseconds*10毫秒的从服务器，down-after-milliseconds是主服务器下线的时间，这一操作避免从服务器与主服务器过早的断开，影响到从库中数据同步，因为断开时间越久，从库里面的数据就越老旧过时。
然后对这些服务器根据slave-priority优先级(这个优先级是手动设置的，比如希望那个从服务器优先变成主服务器，优先级就设置的高一点) 进行排序。
如果几台从服务器优先级相同，然后根据复制偏移量从大到小进行排序，如果还有相同偏移量的从服务器，然后按照 runID 从小到大进行排序，直到选出一台从服务器。
哨兵进行主节点切换
当根据选举规则，选出了可以成为主节点的从节点，如何进行切换呢？
在哨兵中也是有一个 Leader 节点的，当一个从库被选举出来，从库的切换是由 Leader 节点完成的。
Leader 节点的选举用的是 Raft 算法，关于什么是 Raft 算法可参考Raft一致性算法原理
在raft算法中，在任何时刻，每一个服务器节点都处于这三个状态之一：
- Follower:追随者，跟随者都是被动的：他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求；
- Candidate:候选人，如果跟随者接收不到消息，那么他就会变成候选人并发起一次选举，获得集群中大多数选票的候选人将成为领导者。
- Leader:领导者，系统中只有一个领导人并且其他的节点全部都是跟随者，领导人处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给领导人）
哨兵节点的选举总结起来就是：
1、每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为领导者；
2、接收到的sentinel可以同意或者拒绝；
3、如果该sentinel节点发现自己的票数已经超过半数并且超过了 quorum，quorum 用来配置判断主节点宕机的哨兵节点数。简单点讲就是：如果 Sentinel 集群有 quorum 个哨兵认为 master 宕机了，就「客观」的认为 master 宕机了；
4、如果此过程选举出了多个领导者，那么将等待一段时重新进行选举；
故障转移
- sentinel的领导者从从机中选举出合适的丛机进行故障转移；
- 对选取的从节点进行
slave of no one命令，（这个命令用来让从机关闭复制功能，并从从机变为主机）； - 更新应用程序端的链接到新的主节点；
- 对其他从节点变更 master 为新的节点；
- 修复原来的 master 并将其设置为新的 master 的从机。
消息通知
哨兵和哨兵之前，哨兵和从库之间，哨兵和客户端是如何相互发现，进行消息传递？
哨兵和哨兵之间的相互发现，通过 Redis 提供的pub/sub机制实现，因为每个哨兵节点都会和主库进行连接，通过在主库中发布信息，订阅信息，就能找到其他实例的连接信息。
哨兵节点和从库，通过哨兵向主库发送 INFO 命令来完成，哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。
哨兵和客户端之间：每个哨兵实例也提供pub/sub机制，客户端可以从哨兵订阅消息，来获知主从库切换过程中的不同关键事件。
哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的 pubsub（switch-master） 中。客户端需要订阅这 个pubsub，当这个 pubsub 有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。
如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。
哨兵集群
链接redis集群
1，应用端配置所有哨兵节点的信息，来连接我们的redis主从集群。
2，通过哨兵获取主信息：
root@VM-2-10-ubuntu:~# redis-cli -p 26380
127.0.0.1:26380> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
3，配置哨兵的相关配置，可以达到一个通知的效果。
sentinel client-reconfig-script mymaster /usr/local/redis/scripts/reconfig.sh
当哨兵发生切换的时候，会调用/usr/local/redis/scripts/reconfig.sh脚本并且会传入参数：
并且在脚本中依次传入参数：
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
Redis Cluster方案
1、Redis Cluster方案采用哈希槽来处理 KEY 在不同实例中的分布，一个切片集群共有16384个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的key，被映射到一个哈希槽中。
2、一个 KEY ，首先会根据CRC16算法计算一个16 bit的值；然后，再用这个 16bit 值对 16384 取模，得到0~16383范围内的模数，每个模数代表一个相应编号的哈希槽。
3、然后把哈希槽分配到所有的实例中，例如，如果集群中有N个实例，那么，每个实例上的槽个数为16384/N个。
当然这是平均分配的，如果平均分配额哈希槽中，某一个实例中 KEY，存储的数据比较大，造成某一个实例的内存过大，这时候可以通过cluster addslots手动调节哈希槽的分配。
