分布式缓存技术redis学习系列（六）——sentinel哨兵机制

一、简介：

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

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

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

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

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

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

Redis Sentinel 兼容 Redis 2.4.16 或以上版本，推荐使用 Redis 2.8.0 或以上的版本。

二、启动 Sentinel

方式一：使用sentinel可执行文件 redis-sentinel 程序来启动 Sentinel 系统，命令如下：

redis-sentinel /path/to/sentinel.conf

方式二：sentinel只是运行在特殊模式下的redis服务器，你可以用启动redis服务的命令来启动一个运行在 Sentinel 模式下的 Redis 服务器：

redis-server /path/to/sentinel.conf --sentinel

启动 Sentinel 实例必须指定相应的配置文件，系统会使用配置文件来保存 Sentinel 的当前状态，并在 Sentinel 重启时通过载入配置文件来进行状态还原。
Redis 源码中包含了一个名为 sentinel.conf 的文件，这个文件是一个带有详细注释的 Sentinel 配置文件示例，与 redis.conf 配置文件同目录。

三、配置 Sentinel

运行一个 Sentinel 所需的示例配置如下所示：

1、port 263792、dir /usr/local/redis/sentinel3、daemonize yes4、logfile "/usr/local/redis/sentinel/log/sentinel.log"5、sentinel monitor mymaster 127.0.0.1 6379 26、sentinel down-after-milliseconds mymaster 50007、sentinel failover-timeout mymaster 1800008、sentinel parallel-syncs mymaster 19、sentinel notification-script mymaster /var/redis/notify.sh

1、port :当前 Sentinel服务运行的端口

2、dir : Sentinel服务运行时使用的临时文件夹，默认为 /tmp

3、设置sentinel后台运行，即以守护进程的方式运行

4、设置sentinel的日志输出文件

5、sentinel monitor mymaster 127.0.0.1 6379 2 : Sentinel去监视一个名为 mymaster 的主redis实例，它的IP地址为127.0.0.1 ，端口号为 6379 ，而将这个主实例判断为失效至少需要 2 个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover(故障转移)就不会执行。

6、sentinel down-after-milliseconds mymaster 5000 : 指定了Sentinel认为Redis实例已经失效所需的毫秒数。 当实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行。

7、sentinel failover-timeout mymaster 180000 ：如果在该时间（ms）内未能完成failover操作，则认为该failover失败。

8、sentinel parallel-syncs mymaster 1 ：指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长

9、sentinel notification-script ： 指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，但是很常用

运行一个 Sentinel 所需的最少配置如下所示：

sentinel monitor mymaster 127.0.0.1 6379 1

注意：sentinel启动之后，会把默认配置以及非官方配置（比如设置守护进程与日志输出的配置）注释，并会重写sentinel.conf配置，启动之后可以看看配置文件的变化，重启的时候一定要关注此时配置，很可能与之前预想的配置不一样了

四、主观下线与客观下线概念

主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

五、自动发现 Sentinel 和从服务器

1、发现其它的sentinel：

一个 Sentinel 可以与其他多个 Sentinel 进行连接，各个 Sentinel 之间可以互相检查对方的可用性，并进行信息交换。

你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址，因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ，这一功能是通过向频道 sentinel:hello 发送信息来实现的。

2、发现从服务器：

与此类似，你也不必手动列出主服务器属下的所有从服务器，因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。

六、sentinel运行机制

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

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，那么这个实例会被 Sentinel 标记为主观下线。

一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。

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

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

在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。

当一个主服务器被 Sentinel 标记为客观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

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

出现故障的服务器重新启动，sentinel将其作为slave分配给前面重新选定的master。

配置文件的变化：所有slave的redis.conf中的slaveof被重写，sentinel.conf配置监控的主服务也会被替换

参考：http://www.2cto.com/database/201505/399816.html