共计 3482 个字符，预计需要花费 9 分钟才能阅读完成。
Redis Sentinel 哨兵模式
1. 网络架构
网络结构如下，通过 Sentinel 监控 Master 和 Slave 服务器：
2. 配置启动
配置文件如下：
vi /etc/redis-sentinel.conf
port 26379
dir “/tmp”
logfile “/var/log/redis/sentinel_20086.log”
# 进程守护
daemonize yes
# 格式：sentinel <option_name> <master_name> <option_value>
# 最后的一个 2 代表在 sentinel 集群中，多少个节点认为 master 死了，才能真正认为该 master 不可用
sentinel monitor T1 127.0.0.1 6379 2
# sentinel 会向 master 发送心跳确认存活
# 如果 master 在“一定时间范围”内不回应 PONG 或者是回复了一个错误消息
# 那么这个 sentinel 会主观地认为这个 master 已经不可用了
# (subjectively down, 也简称为 SDOWN)。
# down-after-milliseconds 用来指定这个“一定时间范围”，单位是毫秒，默认 30 秒。
sentinel down-after-milliseconds T1 15000
# failover 过期时间。
# 当 failover 开始后，在此时间内仍然没有触发任何 failover 操作，当前 sentinel 将会认为此次 failoer 失败。
# 默认 180 秒，即 3 分钟。
sentinel failover-timeout T1 120000
# 在发生 failover 时，这个选项指定了最多可以有多少个 slave 同时对新的 master 进行同步。
# 这个数字越小，完成 failover 所需的时间就越长；
# 这个数字越大，就意味着越多的 slave 因为 replication 而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。
sentinel parallel-syncs T1 1
# sentinel 连接密码验证
# sentinel auth-pass <master_name> xxxxx
# 发生切换之后执行的一个自定义脚本
# sentinel notification-script <master-name> <script-path>
# sentinel client-reconfig-script <master-name> <script-path>
Sentinel 也需要集群化，以确保：
某个 / 些 Sentinel 节点挂了，仍然可以实现 Redis 主从切换；
Redis 客户端可以通过任意一个 Sentinel 读取 / 写入信息。
启动 Sentinel：
redis-sentinel /path/to/sentinel.conf
启动后，通过 Sentinel 的自动识别，配置文件中会自动加上已识别的 Redis 集群节点和 Sentinel 集群节点。
3. 实现流程
Sentinel 集群通过配置文件发现 master，启动时会监控 master；
向 master 发送 info 命令，获取其所有 slave 节点；
Sentinel 集群向 Redis 主从服务器发送 hello 信息（心跳），包括 Sentinel 本身的 ip、端口、id 等内容，以此来向其他 Sentinel 宣告自己的存在；
Sentinel 集群通过订阅接收其他 Sentinel 发送的 hello 信息，以此来发现监视同一个主服务器的其他 Sentinel；集群之间会互相创建命令连接用于通信，因为已经有主从服务器作为发送和接收 hello 信息的中介，Sentinel 之间不会创建订阅连接；
Sentinel 集群使用 ping 命令来检测实例的状态，如果在指定的时间内（down-after-milliseconds）没有回复或则返回错误的回复，那么该实例被判为下线；
当 failover 主备切换被触发后，并不会马上进行，还需要 Sentinel 中的大多数 sentinel 授权后才可以进行 failover，即进行 failover 的 Sentinel 会去获得指定 quorum 个的 Sentinel 的授权，成功后进入 ODOWN 状态。如在 5 个 Sentinel 中配置了 2 个 quorum，等到 2 个 Sentinel 认为 master 死了就执行 failover。
Sentinel 向选为 master 的 slave 发送 SLAVEOF NO ONE 命令，选择 slave 的条件是 Sentinel 首先会根据 slaves 的优先级来进行排序，优先级越小排名越靠前。如果优先级相同，则查看复制的下标，哪个从 master 接收的复制数据多，哪个就靠前。如果优先级和下标都相同，就选择进程 ID 较小的。
Sentinel 被授权后，它将会获得宕掉的 master 的一份最新配置版本号 (config-epoch)，当 failover 执行结束以后，这个版本号将会被用于最新的配置，通过广播形式通知其它 sentinel，其它的 sentinel 则更新对应 master 的配置。
注意：因为 redis 采用的是异步复制，没有办法避免数据的丢失。可以在 redis.conf 通过以下配置来使得数据不会丢失：
// master 最少得有多少个健康的 slave 存活才能执行写命令
min-slaves-to-write 1
// 延迟小于 min-slaves-max-lag 秒的 slave 才认为是健康的 slave
min-slaves-max-lag 10
当所有 Slave 都不符合条件时，master 将停止写入。
4. 故障转移
发生故障转移时，需要进行领导者选举。
sentinel 首先会根据 slaves 的优先级来进行排序，优先级越小排名越靠前；
如果优先级相同，则查看复制的下标，哪个从 master 接收的复制数据多，哪个就靠前；
如果优先级和下标都相同，就选择 RunID 较小的那个；
如果一个 redis 的 slave 优先级配置为 0，那么它将永远不会被选为 master。
故障转移过程
领导者 Sentinel 需要将一个 salve 提升为 master，此 slave 必须为状态良好，不能处于 SDOWN/ODOWN 状态。
“+failover-triggered”: Leader 开始进行 failover，此后紧跟着“+failover-state-wait-start”，wait 数秒。
“+failover-state-select-slave”: Leader 开始查找合适的 slave
“+selected-slave”: 已经找到合适的 slave
“+failover-state-sen-slaveof-noone”: Leader 向 slave 发送“slaveof no one”指令，此时 slave 已经完成角色转换，此 slave 即为 master
“+failover-state-wait-promotition”: 等待其他 sentinel 确认 slave
“+promoted-slave”：确认成功
“+failover-state-reconf-slaves”: 开始对 slaves 进行 reconfig 操作
“+slave-reconf-sent”: 向指定的 slave 发送“slaveof”指令，告知此 slave 跟随新的 master
“+slave-reconf-inprog”: 此 slave 正在执行 slaveof + SYNC 过程，如过 slave 收到“+slave-reconf-sent”之后将会执行 slaveof 操作。
“+slave-reconf-done”: 此 slave 同步完成，此后 leader 可以继续下一个 slave 的 reconfig 操作。循环 step 7
“+failover-end”: 故障转移结束
“+switch-master”：故障转移成功后，各个 sentinel 实例开始监控新的 master。
5. 增加和删除节点
Sentinel 会通过 PUB/SUB 自动识别新增节点。
删除流程：
停止所要删除的 sentinel
发送一个 SENTINEL RESET 命令给所有其它的 sentinel 实例，如果你想要重置指定 master 上面的 sentinel，只需要把号改为特定的名字，注意，需要一个接一个发，每次发送的间隔不低于 30 秒（down-after-milliseconds）；
检查一下所有的 sentinels 是否都有一致的当前 sentinel 数；
参考资料：https://www.cnblogs.com/zhouj…http://www.cnblogs.com/zhouji…https://segmentfault.com/u/be…
