共计 2986 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章主要介绍“Redis Sentinel 哨兵模式的原理及配置”，在日常操作中，相信很多人在 Redis Sentinel 哨兵模式的原理及配置问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Redis Sentinel 哨兵模式的原理及配置”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
一. 安装配置
在 1 个 master 1 个 slave 的环境中加一个 sentinel，
进入 redis 源码安装目录 copy sentinel.conf 文件
# cd /u01/packages/redis-3.0.6
# cp sentinel.conf /usr/local/redis/etc/
# vi /usr/local/redis/etc/sentinel.conf
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
参数解释：
sentinel monitor mymaster 127.0.0.1 6379 1
指示 Sentinel 去监视一个被命名为 mymaster 的 master，可指定为任何名字
Master IP 为 127.0.0.1，端口号为 6379，
这个 master 判断为失效至少需要 1 个 Sentinel 同意（只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
注意，无论你设置多少个 Sentinel 同意才能判断一个服务器失效，一个 Sentinel 都需要获得系统中多数（majority）Sentinel 的支持，才能发起一次自动故障迁移
sentinel down-after-milliseconds mymaster 30000
down-after-milliseconds 指定了 Sentinel 认为 master 已经断线所需的毫秒数
sentinel parallel-syncs mymaster 1
parallel-syncs 指定了在执行故障转移时，最多可以有多少个 slave 同时对新的 master 进行同步，这个数字越小，完成故障转移所需的时间就越长
sentinel failover-timeout mymaster 180000
failover-timeout 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为 3 分钟
启动 sentinel
# redis-sentinel /usr/local/redis/etc/sentinel.conf
查看状态
# redis-cli -p 26379
127.0.0.1:26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=1,sentinels=1
至此，配置 sentinel 工作完成
Sentinel 相关命令
• INFO sentinel 的基本状态信息
• PING：返回 PONG
• SENTINEL masters：列出所有被监视的 master，以及这些 master 的当前状态
• SENTINEL slaves master name：列出给定 master 的所有 slave 服务器，以及这些 slave 的当前状态
• SENTINEL get-master-addr-by-name master name：返回给定名字的 master 的 IP 地址和端口号。如果这个 master 正在执行故障转移操作，或者针对这个 master 的故障转移操作已经完成，那么这个命令返回新的 master 的 IP 地址和端口号。
• SENTINEL reset pattern：重置所有名字和给定模式 pattern 相匹配的 master。pattern 参数是一个 Glob 风格的模式。重置操作清除 master 目前的所有状态，包括正在执行中的故障转移，并移除目前已经发现和关联的，master 的所有 slave 和 Sentinel
• SENTINEL failover master name：当 master 失效时，在不询问其他 Sentinel 意见的情况下，强制开始一次自动故障迁移（不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
二. 原理：
故障转移时主要是解决两个问题，一是选 Leader Sentinel，二是选新的 master
1. 选 Leader Sentinel 规则
Sentinel 自动故障迁移使用 Raft 算法来选举领头（Leader）Sentinel，从而确保在一个给定的纪元时期（epoch）里，只有一个 Leader 产生。
表示在同一个时期，不会有两个 Sentinel 同时被选中为 Leader，并且各个 Sentinel 在同一个时期中只会对一个 Leader 进行投票。
注：Raft 算法主要思想是同一期 Term(Epoch)投票中少数服从多数原则达成一致，选出 Leader
具体算法这里不过多解释，详细可参考文章：
https://www.jianshu.com/p/8e4bbe7e276c
2. 选新 master 规则
1 在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。
2 在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。
3 在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出复制偏移量（replication offset）最大的那个 slave 作为新的 master 服务器；如果复制偏移量不可用，或者 slave 服务器的复制偏移量相同，那么带有最小运行 ID 的那个从服务器成为新的 master。
一次故障转移步骤：
1 发现 master 已进入客观下线状态。
2 对当前纪元时期 (epoch) 进行自增，并尝试在这个纪元时期中当选。
3 如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤
4 选出一个 slave，并将它升级为 master。
5 向被选中的 slave 发送 SLAVEOF NO ONE 命令，让它转变为 master。
通过发布与订阅功能，将更新后的配置传播给所有其他 Sentinel，其他 Sentinel 对它们自己的配置进行更新。
6 向已下线 master 的其它 slave 发送 SLAVEOF host port 命令，让它们去复制新的 master。
7 当所有 slave 都已经开始复制新的 master 时，领头 Sentinel 终止这次故障迁移操作。
到此，关于“Redis Sentinel 哨兵模式的原理及配置”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
