Redis的哨兵机制 Sentinel(简要)

集群最小单位为：1个Sentinel、2个redis；

启动后Sentinel会：

以10秒一次的频率，向被监视的master发送info命令，根据回复获取master当前信息。

以1秒一次的频率，向所有redis服务器、包含sentinel在内发送PING命令，通过回复判断服务器是否在线。

以2秒一次的频率，通过向所有被监视的master，slave服务器发送包含当前sentinel，master信息的消息。

另外建议sentinel至少起3个实例以上，并配置2个实例同意即可发生转移。 5个实例，配置3个实例同意以此类推。

---

---

redis-sentinel 配置项说明

1. sentinel监听端口，默认是26379，可以修改。

port 26379

2.sentinel monitor <master-name> <ip> <redis-port> <quorum>

告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效。master-name只能包含英文字母，数字，和“.-_”这三个字符需要注意的是master-ip 要写真实的ip地址而不要用回环地址（127.0.0.1）。

配置示例：

sentinel monitor mymaster 192.168.0.5 6379 2

3.sentinel auth-pass <master-name> <password>

设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。

配置示例：

sentinel auth-pass mymaster 0123passw0rd

4.sentinel down-after-milliseconds <master-name> <milliseconds>

选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。

将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。单位是毫秒，默认为30秒

配置示例：

sentinel down-after-milliseconds mymaster 30000

5.sentinel parallel-syncs <master-name> <numslaves>

选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

配置示例：

sentinel parallel-syncs mymaster 1

6. sentinel failover-timeout <master-name> <milliseconds>

failover-timeout 可以用在以下这些方面：

      1. 同一个sentinel对同一个master两次failover之间的间隔时间。

      2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。

      3.当想要取消一个正在进行的failover所需要的时间。 

      4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。

配置示例：

sentinel failover-timeout mymaster1 20000

7.sentinel的notification-script和reconfig-script是用来配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。对于脚本的运行结果有以下规则：

        若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10

        若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。

        如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。

        一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

1).sentinel notification-script <master-name> <script-path>

通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。

  配置示例：

 sentinel notification-script mymaster /var/redis/notify.sh

2).sentinel client-reconfig-script <master-name> <script-path>

 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:

       <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>

目前<state>总是“failover”, <role>是“leader”或者“observer”中的一个。 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的。这个脚本应该是通用的，能被多次调用，不是针对性的。

   配置示例：

   sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

启动 sentinel

nohup redis-server /etc/redis/sentinel.conf --sentinel  &

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 。

相关术语说明

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 命令返回有效回复时， 主服务器的主管下线状态就会被移除。

---

---

Redis-sentinel原理分析

1）SDOWN 和 ODOWN 转换过程

【名词解释】

　　SDOWN:subjectively down，直接翻译的为”主观”失效，即当前 sentinel 实例认为某个redis 服务为”不可用”状态。

　　ODOWN:objectively down，直接翻译为”客观”失效，即多个 sentinel 实例都认为 master处于”SDOWN”状态，那么此时 master 将处于 ODOWN，ODOWN 可以简单理解为 master已经被集群确定为”不可用”，将会开启 failover。

　　（ SDOWN 适合于 master 和 slave，但是 ODOWN 只会使用于 master；当 slave 失效超过”down-after-milliseconds”后，那么所有 sentinel 实例都会将其标记为”SDOWN”。）

【转换过程】

　　a.每个 sentinel 实例在启动后，都会和已知的 slaves/master 以及其他 sentinels 建立 TCP连接,并周期性发送 PING(默认为 1 秒)；

　　b.在交互中，如果 redis-server 无法在”down-after-milliseconds”时间内响应或者响应错误信息，都会被认为此 redis-server 处于 SDOWN 状态；

　　c.如果 b.中 SDOWN 的 server 为 master， 那么此时 sentinel 实例将会向其他 sentinel 间歇性(一秒)发送”is-master-down-by-addr “指令并获取响应信息， 如果足够多的 sentinel 实例检测到 master 处于 SDOWN，那么此时当前 sentinel 实例标记 master 为 ODOWN…其他 sentinel实例做同样的交互操作.配置项”sentinel monitor “，如果检测到 master 处于 SDOWN 状态的slave 个数达到，那么此时此 sentinel 实例将会认为 master 处于 ODOWN；

　　d.每个 sentinel 实例将会间歇性(10 秒)向 master 和 slaves 发送”INFO”指令，如果 master失效且没有新 master 选出时，每 1 秒发送一次”INFO”；”INFO”的主要目的就是获取并确认当前集群环境中 slaves 和 master 的存活情况；

　　经过上述过程后，所有的 sentinel 对 master 失效达成一致后，开始 failover。

2） Sentinel 与 slaves”自动发现”机制

　　在 sentinel 的配置文件中(local-sentinel.conf)，都指定了 port，此 port 就是 sentinel 实例侦听其他 sentinel 实例建立链接的端口.在集群稳定后，最终会每个 sentinel 实例之间都会建立一个 tcp 链接，此链接中发送”PING”以及类似于”is-master-down-by-addr”指令集，可用用来检测其他 sentinel 实例的有效性以及”ODOWN”和”failover”过程中信息的交互。

　　在 sentinel 之间建立连接之前，sentinel 将会尽力和配置文件中指定的 master 建立连接。sentinel 与 master 的连接中的通信主要是基于 pub/sub 来发布和接收信息，发布的信息内容包括当前 sentinel 实例的侦听端口。

3）Leader 选举

　　其实在 sentinels 故障转移中，仍然需要一个“Leader”来调度整个过程：master 的选举以及 slave 的重配置和同步。当集群中有多个 sentinel 实例时，如何选举其中一个 sentinel 为leader 呢？

　　redis2.8.7的选举有两个条件，首先是要下面的条件过滤掉一些节点

使用如下条件筛选备选node：

1、slave节点状态处于S_DOWN,O_DOWN,DISCONNECTED的除外

2、最近一次ping应答时间不超过5倍ping的间隔（假如ping的间隔为1秒，则最近一次应答延迟不应超过5秒，redis sentinel默认为1秒）

3、info_refresh应答不超过3倍info_refresh的间隔（原理同2,redis sentinel默认为10秒）

4、slave节点与master节点失去联系的时间不能超过（ (now - master->s_down_since_time) + (master->down_after_period * 10)）。总体意思是说，slave节点与master同步太不及时的（比如新启动的节点），不应该参与被选举。

5、Slave priority不等于0（这个是在配置文件中指定，默认配置为100）。 从备选node中，按照如下顺序选择新的master

1、较低的slave_priority（这个是在配置文件中指定，默认配置为100）

2、较大的replication offset（每个slave在与master同步后offset自动增加）

3、较小的runid（每个redis实例，都会有一个runid,通常是一个40位的随机字符串,在redis启动时设置，重复概率非常小）

4、如果以上条件都不足以区别出唯一的节点，则会看哪个slave节点处理之前master发送的command多，就选谁。

我们期望有足够多的sentinel实例， 这样能够确保当leader失效时， 能够选举某个sentinel为 leader，以便进行 failover。如果 leader 无法产生，比如较少的 sentinels 实例有效，那么failover 过程将无法继续。

4）failover 过程

　　在 Leader 触发 failover 之前，首先 wait 数秒(随即 0~5)，以便让其他 sentinel 实例准备和调整，如果一切正常，那么 leader 就需要开始将一个 salve 提升为 master，此 slave 必须为状态良好(不能处于 SDOWN/ODOWN 状态)且权重值最低(redis.conf 中)的， 当 master 身份被确认后，开始 failover。