对于master的宕机之后的冷处理是无法实现高可用的。Redis2.6开始提供高可用的解决方案--Sentinel 哨兵机制。
在Redis集群中增加一个节点，充当Sentinel哨兵，用来监视master运行状态，在master宕机后，自动指定一个slave充当新的master，整个过程无需人工参与，由哨兵自动完成。
但是，如果这个Sentinel哨兵发生故障，整个集群就会瘫痪，这要怎么解决？
为Sentinel 创建一个集群，一个哨兵宕机，不会影响整个Redis集群的运行。
那这些Sentinel 哨兵是如何工作的呢？
每个Sentinel 都会定时向master发送心跳，如果master在有效时间内回应了，说明master运行正常。
如果Sentinel集群中有quorum 个哨兵没有收到回应，就认为master宕机了，然后会有一个Sentinel做Failover 故障转移。也就是将某个slave晋升为新的master。
将Redis安装目录中的sentinel.conf复制到cluster目录中。
该文件用于存放sentinel集群的公共配置。
指定sentinel要监控的master是谁【ip port】，并为master起名。该名称会在后面的配置中使用。
同时指定sentinel集群中决定master 宕机判断的 quorum 数量。
quorum的另一个作用是：在sentinel的Leader选举时，至少要有max（quorum，sentinelNum/2 + 1）个sentinel参与，选举才能进行。
这里需要注释掉这个配置，因为要在后面的其他配置文件中设置。
如果master主机设置了访问密码，该属性指定master的主机名与访问密码。
在cluster目录下新建这三个文件作为Sentinel的配置文件
先启动三个Redis，并设置主从关系（可以在slave的配置文件里设置replicaof 192.168.1.100 6379 来设置为他的slave，避免每次启动后都要输入命令，这种方式不用输入命令就直接设置好主从关系了。）
启动Sentinel集群。
首先，redis-server 和redis-sentinel 命令本质上是同一个命令。
之所以可以启动不同的进程，是因为启动时所加载的配置文件不同。所以在启动Sentinel时，要指定sentinel.conf文件。
两种启动方式：redis-sentinel sentinel26380.conf 或者 redis-server sentinel26380.conf --sentinel
启动三台sentinel后，可以通过info sentinel 查看基本信息。
在公共的sentinel.conf文件中，可以设置一些属性值对sentinel进行优化。
每个sentinel会定期发送ping命令来判断master、slave及其他sentinel 是否存活。
如果在指定时间内没收到响应，sentinel就会主观认为该主机宕机。这个时间默认30秒。
该属性用于指定在故障转移期间（原master宕机，新master晋升后），允许多少个slave同时从新master进行数据同步。默认1表示所有slave逐个从新master进行数据同步
指定故障转移超时时间，默认3分钟。该超时时间的用途有：
指定是否可以通过命令sentinel set 动态修改notification-script 和client-reconfig-script 两个脚本。
默认禁止，如果允许动态修改，可能会引发安全问题。
当redis-cli 连接上sentinel 后，通过sentinel set 命令 可同台修改配置信息，比如执行：
sentinel set mymaster quorum 2
sentinel set命令支持的参数有：
sentinel 维护了三个定时任务以检测Redis节点和其他sentinel节点的状态
info任务
每个sentinel 每10秒向Redis集群中的每个节点发送info命令，以获取最新的Redis拓扑结构。
心跳任务
每个sentinel 每1秒向所有Redis节点及其他sentinel节点（这里好像sentinel不知道其他sentinel地址）发送一条ping命令，检测这些节点是否存活。
发布/订阅任务
每个Sentinel节点在启动时会向所有Redis节点订阅__sentinel__:hello主题的信息，当Redis节点中该主题的信息发生变化，就会立即通知到所有订阅者（这时就能获取到其他sentinel的信息）。
当sentinel节点收到主题信息后，会读取并解析这些信息，然后完成以下工作：
每个sentinel 每秒向Redis节点发送心跳检测，如果Sentinel在down-after-milliseconds 时间内没收到回复，则Sentinel节点对该Redis节点做出“下线”判断。这个判断只是当前Sentinel节点认为的。所以称为主观下线
当sentinel 主观下线的节点是master时，该sentinel节点会向其他sentinel节点询问对master节点的判断。
其他sentinel 节点会响应0（在线）或1（下线）。
当sentinel 收到超过quorum 个下线判断后，就会对master做出客观下线判断。
当Sentinel 做出客观下线判断后，由Sentinel Leader 来完成后续的故障转移。
Leader 选举是通过Raft算法实现。
Raft算法大致思路如下：
每个选举参与者都有当选Leader的资格。
当完成“客观下线”判断后，会立即“毛遂自荐”推选自己当选Leader，将自己的提案给所有参与者。
其他参与者收到提案后，只要手中的选票投出去。就会通过该提案并将同意结果反馈给提案者。
后续再过来的提案会由于参与者没有选票而被拒绝。
当提案者收到同意数量大于max（quorum，sentinelNum/2 +1）时，就当选Leader
注意：
sentinel Leader 复制故障转移，步骤如下：
slaveof <masterIP> <masterport> 指令，使他们称为新master的slave不同类型的节点上线方式不同
原Redis节点上线
无论是master还是slave，只要是Redis集群的节点上线，只要启动Redis即可。
Sentinel会定时查看这些节点是否恢复，如果已恢复，就会从当前的master进行数据同步。
如果是原master上线，新master晋升后，sentinel Leader 会立即将原master 更新为slave，然后才定期查看其是否恢复。
新Redis节点上线
在Redis集群内新增一个节点，上线需要手动完成。
添加之前必须知道当前的master，在启动后运行slaveof 命令加入集群。
Sentinel节点上线
添加之前必须知道当前master，在配置文件内修改sentinel monitor 属性，指定当前master，然后启动sentinel。
CAP定理指在一个分布式系统中，一致性 Consistency、可用性 Available、分区容错性 Partition tolerance，三者不可兼得。
由于分布式系统的网络环境不可控，因此系统必须具备分区容错性，但系统不能同时保证一致性和可用性。
即，要么CP，要么AP。
BASE 是Basically Available（基本可以）、Soft state（软状态）、Eventually consistent（最终一致性） 三个短语的简写。
BASE 是对CAP中一致性和可用性权衡的结果，是基于CAP逐步演化而来。
BASE 的思想是：即使无法做到强一致性，但可以根据自身业务特点，采用适当方式达到最终一致性。
基本可用指分布式系统在出现不可预知故障时，允许损失部分可用性。
软状态指数据存在的中间状态，认为该中间状态不会影响系统的整体可用性。即允许主机间进行数据同步的过程存在延迟。
软状态就是一种灰度状态、过度状态。
最终一致性强调系统中的所有数据副本，在经过一段时间的同步后，最终达到一致的状态。
最终一致性的本质是保证最终数据达到一致，不需要实时一致。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。