Redis Sentinel简介
Redis的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，再通知所有的程序把 master 地址统统改一遍，然后重新上线。毫无疑问，这种故障处理的方法是效率低下的。于是Redis 从 2.8 开始正式提供了 sentinel 架构来解决这个问题。而Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。
Redis Sentinel架构
我们以经典的一主二从架构来说明的 sentinel 的原理。
1.主从切换的过程
1) 每个sentinel节点通过定期监控Master的健康状况。
2）主节点出现故障，两个从节点与主节点失去连接，主从复制失败。
3）sentinel 集群 发现 master 故障后，多个 sentinel 节点对主节点的故障达成一致，在 3 个 sentinel 节点中选择一个作为 leader ，例如，选举出 sentinel-0 节点作为 leader，来负责故障转移。
4）leader sentinel 把一个 slave 节点提升为 master，并让另一个 slave 从新的 master 复制数据，并告知客户端新的 master 的信息。
5）故障的旧 master 上线后，leader sentinel 让它从新的 master 复制数据。
以上就是 sentinel 集群进行故障转移的整体流程，具体的一些细节还会详细介绍，这里先总结一下 sentinel 集群在 redis 主从架构高可用中起到的 4 个作用：
1. 集群监控
sentinel 节点会定期检测 redis 数据节点、其余 sentinel 节点是否故障。
2. 故障转移
实现从节点晋升为主节点并维护后续正确的主从关系。
3. 配置中心
sentinel 架构中，客户端在初始化的时候连接的是 sentinel 集群，从中获取主节点信息。
4. 消息通知
sentinel 节点会将故障转移的结果通知给客户端。
此外，使用 sentinel 集群而不是单个 sentinel 节点去监控 redis 主从架构有两个好处：
1. 对于节点的故障判断由多个 sentinel 节点共同完成，这样可以有效地防止误判。
2. sentinel 集群可以保证自身的高可用性，即某个 sentinel 节点自身故障也不会影响 sentinel 集群的健壮性。
Redis Sentinel原理
Redis Sentinel节点数量设计原则
Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。
运行Sentinel
运行Sentinel有两种方式，如下：
1. redis-sentinel /path/to/sentinel.conf
2. redis-server /path/to/sentinel.conf --sentinel
Sentinel配置
Sentinel的配置文件是sentinel.conf。下面是它的一些配置参数：
sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5
配置文件只需要配置master的信息就好啦，不用配置slave的信息，因为slave能够被自动检测到(master节点中有关于slave的消息)。
主观下线(sdown)
客观下线(odown)