一、哨兵模式
哨兵模式是Redis可用性的解决方案；它由一个或多个 sentinel 实例构成 sentinel 系统；该系统可
以监视任意多个主库以及这些主库所属的从库；当主库处于下线状态，自动将该主库所属的某个从
库升级为新的主库；
客户端来连接集群时，会首先连接 sentinel，通过 sentinel 来查询主节点的地址，然后再连接主
节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 索要主库地址，sentinel 会
将最新的主库地址告诉客户端。通过这样客户端无须重启即可自动完成节点切换。
哨兵模式当中涉及多个选举流程采用的是 Raft 算法的领头选举方法的实现；
一主二从三哨兵
client里面有哨兵的ip和port，哨兵通过选举，告诉client，redis的服务器ip和port，这样client就能连接服务器，主redis出现宕机，那么哨兵也会通过同样的方式告诉client应该连接哪个redis服务器。
二、配置
# sentinel.cnf # sentinel 只需指定检测主节点就行了，通过主节点自动发现从节点 sentinel monitor mymaster 127.0.0.1 6379 2 # 判断主观下线时长 sentinel down-after-milliseconds mymaster 30000 # 指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求越高 sentinel parallel-syncs mymaster 1 # 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟 sentinel failover-timeout mymaster 180000
三、检测异常（主观下线）
sentinel 会以每秒一次的频率向所有节点（其他sentinel、主节点、以及从节点）发送 ping 消
息，然后通过接收返回判断该节点是否下线；如果在配置指定 down-after-milliseconds 时间内，sentinel收到的都是无效回复， 则被判断为主观下线；
四、客观下线
当一个 sentinel 节点将一个主节点判断为主观下线之后，为了确认这个主节点是否真的下线，它
会向其他sentinel 节点进行询问，如果收到一定数量的已下线回复，sentinel 会将主节点判定为客
观下线，并通过领头 sentinel 节点对主节点执行故障转移；
五、故障转移
主节点被判定为客观下线后，开始领头 sentinel 选举，需要一半以上的 sentinel 支持，选举领头
sentinel后，开始执行对主节点故障转移；
- 从从节点中选举一个从节点作为新的主节点
- 通知其他从节点复制连接新的主节点
- 若故障主节点重新连接，将作为新的主节点的从节点
六、使用
- 连接一个哨兵节点，并且获取主节点信息；
SENTINEL GET-MASTER-ADDR-BY-NAME- 验证当前获取的主节点；
ROLE或者INFO REPLICATION- 为当前连接的哨兵节点，添加发布订阅（
PUB/SUB）连接，并且订阅+switch-master频 道；
七、缺点
redis 采用异步复制的方式，意味着当主节点挂掉时，从节点可能没有收到全部的同步消息，这部
分未同步的消息将丢失。如果主从延迟特别大，那么丢失可能会特别多。sentinel 无法保证消息完
全不丢失，但是可以通过配置来尽量保证少丢失。
# 主库必须有一个从节点在进行正常复制，否则主库就停止对外写服务，此时丧失了可用性 min-slaves-to-write 1 # 这个参数用来定义什么是正常复制，该参数表示如果在10s内没有收到从库反馈，就意味着从库同步不正常； min-slaves-max-lag 10
同时，它的致命缺点是不能进行横向扩展（不能添加新的节点）；
