1、Redis Sentinel服务配置

1.1简介

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动Redis Sentinel 。

1.2相关配置

案例：

如果要监控两个redis实例，可以进行如下配置Redis安装目录下sentinel.conf文件：

常规配置：

port 26379

daemonize yes

logfile "/var/log/redis/sentinel.log"

#master 7000

sentinel monitor master1 127.0.0.1 7000 2                #配置master名、ip、port、需要多少个sentinel才能判断[客观下线]（2）

sentinel down-after-milliseconds master-7000 30000      #配置sentinel向master发出ping，最大响应时间、超过则认为主观下线

sentinel parallel-syncs master-7000 1                   #配置在进行故障转移时，运行多少个slave进行数据备份同步(越少速度越快)

sentinel failover-timeout master-7000 180000            #配置当出现failover时下一个sentinel与上一个sentinel对[同一个master监测的时间间隔](最后设置为客观下线)
 

#master 7001

sentinel monitor master2 127.0.0.1 7001 1

sentinel down-after-milliseconds master-7001 30000

sentinel parallel-syncs master-7001 1

sentinel failover-timeout master-7001 180000

特殊配置：

min-slaves-to-write 1

min-slaves-max-lag 10

通过上面的配置，当一个redis是master时，如果它不能向至少一个slave写数据(上面的min-slaves-to-write指定了slave的数量)，它将会拒绝接受客户端的写请求。由于复制是异步的，master无法向slave写数据意味着slave要么断开连接了，要么不在指定时间内向master发送同步数据的请求了(上面的min-slaves-max-lag指定了这个时间)。

1.3 相关术语说明

Sentinel包括两个重要的术语：主观下线和客观下线>

1. 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。

2. 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。

客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。

只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

每个Sentinel实例都执行的定时任务

1. 每个Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。

2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者-MASTERDOWN 。

3. 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。

4. 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。

5. 在一般情况下， 每个 Sentinel 会以每10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

6. 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。

1.4服务日志说明

Sentinel服务启动后会打印一些相关日志信息，以下是相关日志特殊字符说明：

+reset-master instance details> ：主服务器已被重置。

+slave instance details> ：一个新的从服务器已经被 Sentinel 识别并关联。

+failover-state-reconf-slaves instancedetails> ：故障转移状态切换到了reconf-slaves 状态。

+failover-detected instance details>：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。

+slave-reconf-sent instance details>：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。

+slave-reconf-inprog instancedetails> ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。

+slave-reconf-done instance details>：从服务器已经成功完成对新主服务器的同步。

-dup-sentinel instance details> ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。

+sentinel instance details> ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。

+sdown instance details> ：给定的实例现在处于主观下线状态。

-sdown instance details> ：给定的实例已经不再处于主观下线状态。

+odown instance details> ：给定的实例现在处于客观下线状态。

-odown instance details> ：给定的实例已经不再处于客观下线状态。

+new-epoch instance details> ：当前的纪元（epoch）已经被更新。

+try-failover instance details> ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by themajority）。

+elected-leader instance details> ：赢得指定纪元的选举，可以进行故障迁移操作了。

+failover-state-select-slave instancedetails> ：故障转移操作现在处于select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。

no-good-slave instance details> ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。

selected-slave instance details> ：Sentinel 顺利找到适合进行升级的从服务器。

failover-state-send-slaveof-nooneinstance details> ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。

failover-end-for-timeout instancedetails> ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the newmaster anyway）。

failover-end instance details> ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。

+switch-master master name>oldip> oldport> newip> newport> ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。

+tilt ：进入 tilt 模式。

-tilt ：退出 tilt 模式。

1.5测试验证

可以对master-slave进行测试，将master关闭，此时slave会自动充当新的new-master；

当old-master恢复后，会充当new-master的slave，即：在这个过程中，sentinel.conf会被改写，改写为当前监控的主机master服务；

如下图测试所示：

Master服务停止：

Old-Master恢复服务：

以上这篇Redis Sentinel服务配置流程(详解)就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持脚本之家。