Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

它的主要功能有以下几点：

• 不时地监控redis是否按照预期良好地运行;
• 如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
• 能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

Slave选举与优先级

当一个Sentinel准备好了要进行failover，并且收到了其他Sentinel的授权，那么就需要选举出一个合适的slave来作为新的master。 slave的选举主要会评估slave的以下几个方面：

• 与master断开连接的次数
• slave的优先级
• 数据复制的下标（用来评估slave当前拥有多少master的数据）
• 进程ID

如果一个slave与master失去联系超过10次，并且每次都超过了配置的最大失联时间（down-after-milliseconds option）,并且，如果Sentinel在进行failover时发现slave失联，那么这个slave就会被Sentinel认为不适合用来做新master的。

更严格的定义是，如果一个slave持续断开连接的时间超过 (down-after-milliseconds *10) + milliseconds_since_master_is_in_SDOWN_state 就会被认为失去选举资格。 符合上述条件的slave才会被列入master候选人列表，并根据以下顺序来进行排序：

0. Sentinel首先会根据slave的优先级来进行排序，优先级越小排名越靠前
1. 如果优先级相同，则查看复制的下标，哪个从master接收的复制数据多，哪个就靠前
2. 如果优先级和下标都相同，就选择进程ID较小的那个。

一个redis无论是master还是slave，都必须在配置中指定一个slave优先级，master也是可能通过failover变成slave。 如果一个Redis的slave优先级配置为0，那么它将永远不会被选举为master，但是它仍然会从master那里复制数据。

Sentinel和Redis身份认证

当master配置为需要密码才能连接时，客户端和slave在连接时都需要提供密码。 master通过requirepass设置自身的密码，不提供密码无法连接到这个master。 slave通过masterauth来设置访问master时的密码。 当使用了Sentinel时，由于一个master可能会变成一个slave，一个slave也可能会变成master，所以需要同时设置上述两个配置项。

Sentinel “仲裁会”

当一个master被Sentinel集群监控时，需要为其指定一个参数，这个参数指定了当需要判决master为不可用，并且进行failover时所需要的Sentinel数量——票数。 当failover主备切换真正被触发后，failover并不会马上进行，还需要Sentinel中的大多数Sentinel授权后才可进行failover。 当ODOWN时，failover被触发，failover一旦被触发，尝试去进行failover的Sentinel会去获得“大多数” Sentinel的授权。比如：集群中有5个Sentinel，票数被设置为2，当2个Sentinel认为一个master已经不可用了，将会触发failover，但是，进行failover的那个Sentinel必须先获得至少3个Sentinel的授权才可以实行failover。 如果票数被设置成5，要达到ODOWN状态，必须所有5个Sentinel都主观认为不可用，要进行failover，那么得获得所有5个Sentinel的授权。

配置版本号

当一个Sentinel被授权后，它将会获得当掉的master的一份最新配置版本号，当failover执行结束以后，这个版本号将会被用于最新的配置。因为大多数Sentinel都已经知道改版本号已经被要执行failover的Sentinel拿走了，所以其他的Sentinel都不能再去使用这个版本号。意味着，每次failover都会附带有一个独一无二的版本号。 而Sentinel集群都遵守一个规则：如果SentinelA推荐SentinelB去执行failover，A会等待一段时间后自行再去对同一个master执行failover，这个等待的时间通过failover-timeout配置项去配置的。Sentinel集群中的Sentinel不会在同一时刻并发去failover同一个master，第一个进行failover的Sentinel如果失败了，另外一个将会在一定时间内重新进行failover。

• Redis Sentinel保证了活跃性：如果大多数Sentinel能够互相通信，最终将会有一个被授权去进行failover。
• Redis Sentinel保证了安全性：每个试图去failover同一个master的Sentinel都会得到一个独一无二的版本号。
• 一个能够互相通信的Sentinel集群最终会采用版本号最高且相同的配置。

SDOWN和ODOWN细节

SDOWN：主观不可用；ODOWN：客观不可用。 SDOWN是Sentinel自己主观上监测到的关于master的状态，ODOWN需要一定数量的Sentinel达成一致意见才能认为一个master客观上已经当掉。各个Sentinel之间通过命令：sentinel is_master_down_by_addr来获得其他Sentinel对master的监测结果。 从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip协议：如果一个Sentinel收到了足够多的Sentinel发来消息告诉它某个master已经down掉了，SDOWN状态就会变成ODOWN。如果之后master可用了，这个状态就会相应的被清理掉。 真正进行failover需要一个授权的过程，但是所有的failover都开始于一个ODOWN状态。 ODOWN状态只适用于master，对于不是master的Redis节点Sentinel之间不需要任何协商，slaves和Sentinel不会有ODOWN状态。

Sentinel命令

• PING sentinel回复 PONG。
• sentinel masters 显示被监控的所有master以及它们的状态。
• Sentinel master <master name> 显示指定master的信息和状态。
• Sentinel slaves <master name> 显示指定master的所有slaves以及它们的状态。
• Sentinel get-master-addr-by-name <master name> 返回指定master的IP和端口，如果正在进行failover或者已经failover完成，将会显示被提升为master的slave的IP和端口。
• Sentinel reset <parttern> 重置名字匹配该正则表达式的所有的master的状态信息，清除其之前的状态信息，以及slaves信息。
• Sentinel failover <master name> 强制Sentinel执行failover，并且不需要得到其他Sentinel的同意。但是，failover后会将最新的配置发送给其他Sentinel。

增加或删除Sentinel

添加Sentinel简单，只需要监控到某个Master上，然后新增加的Sentinel就能获得其他Sentinel信息以及Master的所有slaves。 删除一个Sentinel比较复杂，因为Sentinel永远不会删除一个已经存在过的Sentinel，即使已经与集群失去联系很久了。 删除Sentinel应遵循以下步骤：

• 停止所要删除的Sentinel；
• 发送一个Sentinel reset * 命令给所有其他的Sentinel实例，如果想要重置指定master上的Sentinel，只需要把*号改为特定的名字。注意，需要一个接一个发，每次发送间隔不低于30秒。
• 检查所有Sentinel是否都由一致的当前Sentinel数——Sentinel Master mastername

Redis sentinel集群中实例的增加、删除操作，可参见我之前发布的文章：Redis主从高可用及哨兵集群的实例增删实践