Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
它的主要功能有以下几点
监控：Sentinel不断的检查master和slave是否正常的运行。
通知：如果发现某个redis节点运行出现问题，可以通过API通知系统管理员和其他的应用程序。
自动故障转移：能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
配置提供者：哨兵作为Redis客户端发现的权威来源：客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。
很显然，只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：
即使有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；
如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;
如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。
当前的哨兵版本是sentinel 2。它是基于最初哨兵的实现，使用更健壮的和更简单的预算算法(在这个文档里有解释)重写的。
Redis2.8和Redis3.0附带稳定的哨兵版本。他们是Redis的两个最新稳定版本。
在不稳定版本的分支上执行新的改进，且有时一些新特性一旦被认为是稳定的就会被移植到Redis2.8和Redis3.0分支中。
Redis2.6附带Redis sentinel 1，它是弃用的不建议使用。
运行Sentinel有两种方式，如下：
redis-sentinel /path/to/sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
两种方式效果都是一样的。
然而在启动哨兵时必须使用一个配置文件，因为这个配置文件将用于系统保存当前状态和在重启时重新加载。哨兵会在没有指定配置文件或指定的配置文件不可写的时候拒绝启动。
Redis 哨兵默认监听26379 TCP端口，所以为了哨兵的正常工作，你的26379端口必须开放接收其他哨兵实例的IP地址的连接。否则哨兵不能通信和商定做什么，故障转移将永不会执行。
一个健壮的部署至少需要三个哨兵实例。
三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。
sentinel + Redis实例不保证在故障期间保留确认的写入，因为Redis使用异步复制。然而有方式部署哨兵使丢失数据限制在特定时刻，虽然有更安全的方式部署它。
你的客户端要支持哨兵，流行的客户端都支持哨兵，但不是全部。
没有HA设置是安全的，如果你不经常的在开发环境测试，在生产环境他们会更好。你可能会有一个明显的错误配置只是当太晚的时候。
Sentinel，Docker，或者其他形式的网络地址交换或端口映射需要加倍小心：Docker执行端口重新映射，破坏Sentinel自动发现其他的哨兵进程和master的slave列表。稍后在这个文档里检查关于Sentinel和Docker的部分，了解更多信息。
Redis源码发布包包含一个sentinel.conf的文件，默认的配置文件中有关于各个配置项的详细解释，一个典型的最小的配置文件就像下面的配置：
sentinel monitor mymaster . -after-milliseconds mymaster -timeout mymaster -syncs mymaster . -after-milliseconds resque -timeout resque -syncs resque
上面的配置项配置了两个名字分别为mymaster和resque的master，配置文件只需要配置master的信息就好啦，不用配置slave的信息，因为slave能够被自动检测到(master节点中有关于slave的消息)。
为了更清晰，我们逐行的解释每个选项的含义：
第一行的格式如下：
sentinel monitor [master-group-name] [ip] [port] [quorum]
master-group-name：master名称
quorun：本文叫做票数，Sentinel需要协商同意master是否可到达的数量。
sentinel monitor mymaster 127.0.0.1 6379 2
这一行用于告诉Redis监控一个master叫做mymaster，它的地址在127.0.0.1，端口为6379，票数是2。
这里的票数需要解释下：举个栗子，redis集群中有5个sentinel实例，其中master挂掉啦，如果这里的票数是2，表示有2个sentinel认为master挂掉啦，才能被认为是正真的挂掉啦。其中sentinel集群中各个sentinel也有互相通信，通过gossip协议。
除啦第一行其他的格式如下：
sentinel [option_name] [master_name] [option_value]
down-after-milliseconds
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地认为这个master已经不可用了。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。
parallel-syncs
在发生failover主从切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成主从故障转移所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为主从同步而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
前面我们谈到，主从故障转移时，需要的sentinel认可的票数达到设置的值才可以。
不过，当failover主备切换真正被触发后，failover并不会马上进行，还需要sentinel中的大多数sentinel授权后才可以进行failover。
当sentinel认可不可用的票数达到时（ODOWN），failover被触发。failover一旦被触发，尝试去进行failover的sentinel会去获得“大多数”sentinel的授权（如果票数比大多数还要大的时候，则询问更多的sentinel)
这个区别看起来很微妙，但是很容易理解和使用。例如，集群中有5个sentinel，票数被设置为2，当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。
如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。
为什么要先获得大多数sentinel的认可时才能真正去执行failover呢？
当一个sentinel被授权后，它将会获得宕掉的master的一份最新配置版本号，当failover执行结束以后，这个版本号将会被用于最新的配置。因为大多数sentinel都已经知道该版本号已经被要执行failover的sentinel拿走了，所以其他的sentinel都不能再去使用这个版本号。这意味着，每次failover都会附带有一个独一无二的版本号。我们将会看到这样做的重要性。
而且，sentinel集群都遵守一个规则：如果sentinel A推荐sentinel B去执行failover，B会等待一段时间后，自行再次去对同一个master执行failover，这个等待的时间是通过failover-timeout配置项去配置的。从这个规则可以看出，sentinel集群中的sentinel不会再同一时刻并发去failover同一个master，第一个进行failover的sentinel如果失败了，另外一个将会在一定时间内进行重新进行failover，以此类推。
redis sentinel保证了活跃性：如果大多数sentinel能够互相通信，最终将会有一个被授权去进行failover.
redis sentinel也保证了安全性：每个试图去failover同一个master的sentinel都会得到一个独一无二的版本号。
一旦一个sentinel成功地对一个master进行了failover，它将会把关于master的最新配置通过广播形式通知其它sentinel，其它的sentinel则更新对应master的配置。
一个faiover要想被成功实行，sentinel必须能够向选为master的slave发送SLAVE OF NO ONE命令，然后能够通过INFO命令看到新master的配置信息。
当将一个slave选举为master并发送SLAVE OF NO ONE`后，即使其它的slave还没针对新master重新配置自己，failover也被认为是成功了的，然后所有sentinels将会发布新的配置信息。
新配在集群中相互传播的方式，就是为什么我们需要当一个sentinel进行failover时必须被授权一个版本号的原因。
每个sentinel使用##发布/订阅##的方式持续地传播master的配置版本信息，配置传播的##发布/订阅##管道是：__sentinel__:hello。
因为每一个配置都有一个版本号，所以以版本号最大的那个为标准。
举个栗子：假设有一个名为mymaster的地址为192.168.1.50:6379。一开始，集群中所有的sentinel都知道这个地址，于是为mymaster的配置打上版本号1。一段时候后mymaster死了，有一个sentinel被授权用版本号2对其进行failover。如果failover成功了，假设地址改为了192.168.1.50:9000，此时配置的版本号为2，进行failover的sentinel会将新配置广播给其他的sentinel，由于其他sentinel维护的版本号为1，发现新配置的版本号为2时，版本号变大了，说明配置更新了，于是就会采用最新的版本号为2的配置。
这意味着sentinel集群保证了第二种活跃性：一个能够互相通信的sentinel集群最终会采用版本号最高且相同的配置。
sentinel对于不可用有两种不同的看法，一个叫主观不可用(SDOWN),另外一个叫客观不可用(ODOWN)。
SDOWN是sentinel自己主观上检测到的关于master的状态。
ODOWN需要一定数量的sentinel达成一致意见才能认为一个master客观上已经宕掉，各个sentinel之间通过命令 SENTINEL is_master_down_by_addr 来获得其它sentinel对master的检测结果。
从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。这个时间在配置中通过 is-master-down-after-milliseconds 参数配置。
当sentinel发送PING后，以下回复都被认为是合法的,除此之外，其它任何回复（或者根本没有回复）都是不合法的。
PING replied with +PONG. PING replied with -LOADING error. PING replied with -MASTERDOWN error.
从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip协议：如果一个sentinel收到了足够多的sentinel发来消息告诉它某个master已经down掉了，SDOWN状态就会变成ODOWN状态。如果之后master可用了，这个状态就会相应地被清理掉。
正如之前已经解释过了，真正进行failover需要一个授权的过程，但是所有的failover都开始于一个ODOWN状态。
ODOWN状态只适用于master，对于不是master的redis节点sentinel之间不需要任何协商，slaves和sentinel不会有ODOWN状态。
虽然sentinel集群中各个sentinel都互相连接彼此来检查对方的可用性以及互相发送消息。但是你不用在任何一个sentinel配置任何其它的sentinel的节点。因为sentinel利用了master的发布/订阅机制去自动发现其它也监控了统一master的sentinel节点。
通过向名为__sentinel__:hello的管道中发送消息来实现。
同样，你也不需要在sentinel中配置某个master的所有slave的地址，sentinel会通过询问master来得到这些slave的地址的。
每个sentinel通过向每个master和slave的发布/订阅频道__sentinel__:hello每秒发送一次消息，来宣布它的存在。
每个sentinel也订阅了每个master和slave的频道__sentinel__:hello的内容，来发现未知的sentinel，当检测到了新的sentinel，则将其加入到自身维护的master监控列表中。
每个sentinel发送的消息中也包含了其当前维护的最新的master配置。如果某个sentinel发现
自己的配置版本低于接收到的配置版本，则会用新的配置更新自己的master配置。
在为一个master添加一个新的sentinel前，sentinel总是检查是否已经有sentinel与新的sentinel的进程号或者是地址是一样的。如果是那样，这个sentinel将会被删除，而把新的sentinel添加上去。
redis sentinel集群的配置的一致性模型为最终一致性，集群中每个sentinel最终都会采用最高版本的配置。然而，在实际的应用环境中，有三个不同的角色会与sentinel打交道：
Redis实例.
Sentinel实例.
客户端.
为了考察整个系统的行为我们必须同时考虑到这三个角色。
下面有个简单的例子，有三个主机，每个主机分别运行一个redis和一个sentinel:
+-------------+ | Sentinel 1 | <--- Client A | Redis 1 (M) | +-------------+ | | +-------------+ | +------------+ | Sentinel 2 |-----+-- / partition / ----| Sentinel 3 | <--- Client B | Redis 2 (S) | | Redis 3 (M)| +-------------+ +------------+
在这个系统中，初始状态下redis3是master, redis1和redis2是slave。之后redis3所在的主机网络不可用了，sentinel1和sentinel2启动了failover并把redis1选举为master。
Sentinel集群的特性保证了sentinel1和sentinel2得到了关于master的最新配置。但是sentinel3依然持着的是就的配置，因为它与外界隔离了。
当网络恢复以后，我们知道sentinel3将会更新它的配置。但是，如果客户端所连接的master被网络隔离，会发生什么呢？
客户端将依然可以向redis3写数据，但是当网络恢复后，redis3就会变成redis的一个slave，那么，在网络隔离期间，客户端向redis3写的数据将会丢失。
也许你不会希望这个场景发生：
如果你把redis当做缓存来使用，那么你也许能容忍这部分数据的丢失。
但如果你把redis当做一个存储系统来使用，你也许就无法容忍这部分数据的丢失了。
因为redis采用的是异步复制，在这样的场景下，没有办法避免数据的丢失。然而，你可以通过以下配置来配置redis3和redis1，使得数据不会丢失。
min-slaves-to-write 1min-slaves-max-lag 10
通过上面的配置，当一个redis是master时，如果它不能向至少一个slave写数据(上面的min-slaves-to-write指定了slave的数量)，它将会拒绝接受客户端的写请求。由于复制是异步的，master无法向slave写数据意味着slave要么断开连接了，要么不在指定时间内向master发送同步数据的请求了(上面的min-slaves-max-lag指定了这个时间)。
snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，可以安全的停止和重启sentinel进程。
即使当前没有failover正在进行，sentinel依然会使用当前配置去设置监控的master。特别是：
根据最新配置确认为slaves的节点却声称自己是master(参考上文例子中被网络隔离后的的redis3)，这时它们会被重新配置为当前master的slave。
如果slaves连接了一个错误的master，将会被改正过来，连接到正确的master。
当一个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候选人列表，并根据以下顺序来进行排序：
sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前（？）。
如果优先级相同，则查看复制的下标，哪个从master接收的复制数据多，哪个就靠前。
如果优先级和下标都相同，就选择进程ID较小的那个。
一个redis无论是master还是slave，都必须在配置中指定一个slave优先级。要注意到master也是有可能通过failover变成slave的。
如果一个redis的slave优先级配置为0，那么它将永远不会被选为master。但是它依然会从master哪里复制数据。
当一个master配置为需要密码才能连接时，客户端和slave在连接时都需要提供密码。
master通过requirepass设置自身的密码，不提供密码无法连接到这个master。
slave通过masterauth来设置访问master时的密码。
但是当使用了sentinel时，由于一个master可能会变成一个slave，一个slave也可能会变成master，所以需要同时设置上述两个配置项。
Sentinel默认运行在26379端口上，sentinel支持redis协议，所以可以使用redis-cli客户端或者其他可用的客户端来与sentinel通信。
有两种方式能够与sentinel通信：
一种是直接使用客户端向它发消息
另外一种是使用发布/订阅模式来订阅sentinel事件，比如说failover，或者某个redis实例运行出错，等等。
sentinel支持的合法命令如下：
PING sentinel回复PONG.
SENTINEL masters 显示被监控的所有master以及它们的状态.
SENTINEL master <master name> 显示指定master的信息和状态；
SENTINEL slaves <master name> 显示指定master的所有slave以及它们的状态；
SENTINEL get-master-addr-by-name <master name> 返回指定master的ip和端口，如果正在进行failover或者failover已经完成，将会显示被提升为master的slave的ip和端口。
SENTINEL reset <pattern> 重置名字匹配该正则表达式的所有的master的状态信息，清楚其之前的状态信息，以及slaves信息。
SENTINEL failover <master name> 强制sentinel执行failover，并且不需要得到其他sentinel的同意。但是failover后会将最新
从redis2.8.4开始，sentinel提供了一组API用来添加，删除，修改master的配置。
需要注意的是，如果你通过API修改了一个sentinel的配置，sentinel不会把修改的配置告诉其他sentinel。你需要自己手动地对多个sentinel发送修改配置的命令。
以下是一些修改sentinel配置的命令：
SENTINEL MONITOR <name> <ip> <port> <quorum> 这个命令告诉sentinel去监听一个新的master
SENTINEL REMOVE <name> 命令sentinel放弃对某个master的监听
SENTINEL SET <name> <option> <value> 这个命令很像Redis的CONFIG SET命令，用来改变指定master的配置。支持多个<option><value>。例如以下实例：
SENTINEL SET objects-cache-master down-after-milliseconds 1000
只要是配置文件中存在的配置项，都可以用SENTINEL SET命令来设置。这个还可以用来设置master的属性，比如说quorum(票数)，而不需要先删除master，再重新添加master。例如：
SENTINEL SET objects-cache-master quorum 5
由于有sentinel自动发现机制，所以添加一个sentinel到你的集群中非常容易，你所需要做的只是监控到某个Master上，然后新添加的sentinel就能获得其他sentinel的信息以及masterd所有的slave。
如果你需要添加多个sentinel，建议你一个接着一个添加，这样可以预防网络隔离带来的问题。你可以每个30秒添加一个sentinel。最后你可以用SENTINEL MASTER mastername来检查一下是否所有的sentinel都已经监控到了master。
删除一个sentinel显得有点复杂：因为sentinel永远不会删除一个已经存在过的sentinel，即使它已经与组织失去联系很久了。要想删除一个sentinel，应该遵循如下步骤：
停止所要删除的sentinel
发送一个SENTINEL RESET * 命令给所有其它的sentinel实例，如果你想要重置指定master上面的sentinel，只需要把*号改为特定的名字，注意，需要一个接一个发，每次发送的间隔不低于30秒。
检查一下所有的sentinels是否都有一致的当前sentinel数。使用SENTINEL MASTER mastername 来查询。
sentinel永远会记录好一个Master的slaves，即使slave已经与组织失联好久了。这是很有用的，因为sentinel集群必须有能力把一个恢复可用的slave进行重新配置。
并且，failover后，失效的master将会被标记为新master的一个slave，这样的话，当它变得可用时，就会从新master上复制数据。
然后，有时候你想要永久地删除掉一个slave(有可能它曾经是个master)，你只需要发送一个SENTINEL RESET master命令给所有的sentinels，它们将会更新列表里能够正确地复制master数据的slave。
客户端可以向一个sentinel发送订阅某个频道的事件的命令，当有特定的事件发生时，sentinel会通知所有订阅的客户端。需要注意的是客户端只能订阅，不能发布。
订阅频道的名字与事件的名字一致。例如，频道名为sdown 将会发布所有与SDOWN相关的消息给订阅者。
如果想要订阅所有消息，只需简单地使用PSUBSCRIBE *
以下是所有你可以收到的消息的消息格式，如果你订阅了所有消息的话。第一个单词是频道的名字，其它是数据的格式。
注意：以下的instance details的格式是：
<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>
如果这个redis实例是一个master，那么@之后的消息就不会显示。
+reset-master <instance details> -- 当master被重置时. +slave <instance details> -- 当检测到一个slave并添加进slave列表时. +failover-state-reconf-slaves <instance details> -- Failover状态变为reconf-slaves状态时 +failover-detected <instance details> -- 当failover发生时 +slave-reconf-sent <instance details> -- sentinel发送SLAVEOF命令把它重新配置时 +slave-reconf-inprog <instance details> -- slave被重新配置为另外一个master的slave，但数据复制还未发生时。 +slave-reconf-done <instance details> -- slave被重新配置为另外一个master的slave并且数据复制已经与master同步时。 -dup-sentinel <instance details> -- 删除指定master上的冗余sentinel时 (当一个sentinel重新启动时，可能会发生这个事件). +sentinel <instance details> -- 当master增加了一个sentinel时。 +sdown <instance details> -- 进入SDOWN状态时; -sdown <instance details> -- 离开SDOWN状态时。 +odown <instance details> -- 进入ODOWN状态时。 -odown <instance details> -- 离开ODOWN状态时。 +new-epoch <instance details> -- 当前配置版本被更新时。 +try-failover <instance details> -- 达到failover条件，正等待其他sentinel的选举。 +elected-leader <instance details> -- 被选举为去执行failover的时候。 +failover-state-select-slave <instance details> -- 开始要选择一个slave当选新master时。 no-good-slave <instance details> -- 没有合适的slave来担当新master selected-slave <instance details> -- 找到了一个适合的slave来担当新master failover-state-send-slaveof-noone <instance details> -- 当把选择为新master的slave的身份进行切换的时候。 failover-end-for-timeout <instance details> -- failover由于超时而失败时。 failover-end <instance details> -- failover成功完成时。 switch-master <master name> <oldip> <oldport> <newip> <newport> -- 当master的地址发生变化时。通常这是客户端最感兴趣的消息了。 +tilt -- 进入Tilt模式。 -tilt -- 退出Tilt模式。
redis sentinel非常依赖系统时间，例如它会使用系统时间来判断一个PING回复用了多久的时间。
然而，假如系统时间被修改了，或者是系统十分繁忙，或者是进程堵塞了，sentinel可能会出现运行不正常的情况。
当系统的稳定性下降时，TILT模式是sentinel可以进入的一种的保护模式。当进入TILT模式时，sentinel会继续监控工作，但是它不会有任何其他动作，它也不会去回应is-master-down-by-addr这样的命令了，因为它在TILT模式下，检测失效节点的能力已经变得让人不可信任了。
如果系统恢复正常，持续30秒钟，sentinel就会退出TITL模式。
注意：该功能还未实现。
当一个脚本的运行时间超过配置的运行时间时，sentinel会返回一个-BUSY 错误信号。如果这件事发生在触发一个failover之前，sentinel将会发送一个SCRIPT KILL命令，如果script是只读的话，就能成功执行。
既然你知道了sentinel的基本信息，你可以很想知道应该将Sentinel放置在哪里，需要多少Sentinel进程等等。这个章节展示了几个部署示例。
我们为了图像化展示配置示例使用字符艺术，这是不同符号的意思：
+--------------------+| This is a computer || or VM that fails || independently. We || call it a "box" |+--------------------+
我们写在盒子里表示他们正在运行什么：
+-------------------+| Redis master M1 || Redis Sentinel S1 |+-------------------+
不同的盒子之间通过线条连接，表示他们可以相互通信：
+-------------+ +-------------+| Sentinel S1 |---------------| Sentinel S2 |+-------------+ +-------------+
使用斜杠展示网络断开：
+-------------+ +-------------+| Sentinel S1 |------ // ------| Sentinel S2 |+-------------+ +-------------+
还要注意：
Master 被叫做 M1,M2,M3 ... Mn。
Slave 被叫做 R1,R2,R3 ... Rn(replica的首字母)
Sentinels 被叫做 S1,S2,S3 ... Sn
Clients 被叫做 C1,C2,C3 ... Cn
当一个实例因为Sentinel的行为改变了角色，我们把它放在方括号里，所以[M1]表示因为Sentinel的介入，M1现在是一个master。
注意永远不会显示的设置只是使用了两个哨兵，因为为了启动故障转移，Sentinel总是需要和其他大多数的Sentinel通信。
+----+ +----+| M1 |---------| R1 || S1 | | S2 |+----+ +----+Configuration: quorum = 1
在这个设置中，如果master M1故障，R1将被晋升因为两个Sentinel可以达成协议并且还可以授权一个故障转移因为多数就是两个。所以他表面上看起来是可以工作的，然而检查下一个点了解为什么这个设置是不行的。
如果运行M1的盒子停止工作了，S1也停止工作。运行在其他盒子上的S2将不能授权故障转移，所以系统将变成不可用。
注意为了排列不同的故障转移需要少数服从多数，并且稍后向所有的Sentinel传播最新的配置。还要注意上面配置的故障转移的能力，没有任何协定，非常危险：
+----+ +------+| M1 |----//-----| [M1] || S1 | | S2 |+----+ +------+
在上面的配置中我们使用完美的对称方式创建了两个master(假定S2可以在未授权的情况下进行故障转移)。客户端可能会不确定往哪边写，并且没有途径知道什么时候分区配置是正确的，为了预防一个永久的断裂状态。
所有请永远部署至少三个Sentinel在三个不同的盒子里。
这是个非常简单的设置，它有简单调整安全的优势。它基于三个盒子，每个盒子同时运行一个Redis实例和一个Sentinel实例。
+----+ | M1 | | S1 | +----+ |+----+ | +----+| R2 |----+----| R3 || S2 | | S3 |+----+ +----+Configuration: quorum = 2
如果M1故障，S2和S3将会商定故障并授权故障转移，使客户端可以继续。
在每个Sentinel设置里，Redis是异步主从复制，总会有丢失数据的风险，因为有可能当它成为master的时候，一个确认的写入操作还没有同步到slave。然后在上面的设置中有一个更高的风险由于客户端分区一直是老的master，就像下面的图像所示：
+----+ | M1 | | S1 | [- C1 (writes will be lost) +----+ | / /+------+ | +----+| [M2] |----+----| R3 || S2 | | S3 |+------+ +----+
在这个案例中网络分区隔离老的master M1，所以slave R2晋升为master。然而客户端，比如C1，还在原来的老的master的分区，可能继续往老master写数据。这个数据将会永久丢失，因为分区恢复时，master将会重新配置为新master的slave，丢弃它的数据集。
这个问题可以使用下面的Redis主从复制特性减轻，它可在master检查到它不再能传输它的写入操作到指定数量的slave的时候停止接收写入操作。
min-slaves-to-write 1min-slaves-max-lag 10
使用上面的配置(请查看自带的redis.conf示例了解更多信息)一个Redis实例，当作为一个master，如果它不能写入至少1个slave将停止接收写入操作。（N个Slave以上不通就停止接收）
由于主从复制是异步的不能真实的写入，意味着slave断开连接，或者不再向我们发送异步确认的指定的max-lag秒数。（判定连接不通的超时时间）
在上面的示例中使用这个配置，老master M1将会在10秒钟后变为不可用。当分区恢复时，Sentinel配置将指向新的一个，客户端C1将能够获取到有效的配置并且将使用新master继续工作。
然而天下没有免费的午餐，这种改进，如果两个slave挂掉，master将会停止接收写入操作。这是个权衡。
有时我们只有两个Redis盒子可用，一个master和一个slave。在例二中的配置在那样的情况下是不可行的，所谓我们可以借助下面的，Sentinel放置在客户端：
+----+ +----+ | M1 |----+----| R1 | | S1 | | | S2 | +----+ | +----+ | +------------+------------+ | | | | | | +----+ +----+ +----+ | C1 | | C2 | | C3 | | S1 | | S2 | | S3 | +----+ +----+ +----+ Configuration: quorum = 2
在这个设置里，Sentinel的视角和客户端的视角相同：如果大多数的客户端认为master是可以到达的，它就是好的。C1,C2,C3是一般的客户端，这不意味着C1识别单独的客户端连接到Redis。它更像一些如应用服务，Rails应用之类的。
如果运行M1和S1的盒子故障，故障转移将会发生，然而很容看到不同的网络分区将导致不同的行为。例如如果客户端和Redis服务之间的断开连接，Sentinel将不能设置，因为master和slave将都不可用。
注意如果使用M1获取分区，我们有一个和例二中描述的相似的问题，不同的是这里我们没有办法打破对称，由于只有一个slave和master，所以当它的master断开连接时master不能停止接收查询，否则在slave故障期间master将永不可用。
所以这是个有效的设置但是在例二中的设置有像更容易管理HA系统的优点， 并有能力限制master接收写入的时间。
在例3中如果客户端少于3个就不能使用。在这个案例中我们使用一个混合的设置：
+----+ +----+ | M1 |----+----| R1 | | S1 | | | S2 | +----+ | +----+ | +------+-----+ | | | | +----+ +----+ | C1 | | C2 | | S3 | | S4 | +----+ +----+ Configuration: quorum = 3
这里和例3非常类似，但是这里我们在4个盒子里运行四个哨兵。如果M1故障其他的三个哨兵可以执行故障转移。
原文地址：http://kiujyhgt.blog.51cto.com/12806908/1916013
