对于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。Sentinel集群搭建复制sentinel.conf将Redis安装目录中的sentinel.conf复制到cluster目录中。该文件用于存放sentinel集群的公共配置。修改sentinel.confsentinel monitor指定sentinel要监控的master是谁【ip port】并为master起名。该名称会在后面的配置中使用。同时指定sentinel集群中决定master 宕机判断的 quorum 数量。quorum的另一个作用是在sentinel的Leader选举时至少要有maxquorumsentinelNum/2 1个sentinel参与选举才能进行。这里需要注释掉这个配置因为要在后面的其他配置文件中设置。sentinel auth-pass如果master主机设置了访问密码该属性指定master的主机名与访问密码。新建sentinel26380.conf、sentinel26381.conf、sentinel26382.conf在cluster目录下新建这三个文件作为Sentinel的配置文件Redis高可用集群启动先启动三个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的配置文件会自动增加很多信息。Sentinel优化配置在公共的sentinel.conf文件中可以设置一些属性值对sentinel进行优化。sentinel down-after-milliseoncds每个sentinel会定期发送ping命令来判断master、slave及其他sentinel 是否存活。如果在指定时间内没收到响应sentinel就会主观认为该主机宕机。这个时间默认30秒。sentinel parallel-syncs该属性用于指定在故障转移期间原master宕机新master晋升后允许多少个slave同时从新master进行数据同步。默认1表示所有slave逐个从新master进行数据同步sentinel failover-timeout指定故障转移超时时间默认3分钟。该超时时间的用途有当第一次故障转移失败在同一个master上进行第二次故障转移尝试的时间为该时间的2倍。新master晋升完毕slave从老master强制转到新master进行数据同步的时间阈值。取小正在进行的故障转移所需时间的阈值。新master晋升完毕所有replicas 的配置文件更新为新master的时间阈值。sentinel deny-scripts-reconfig指定是否可以通过命令sentinel set 动态修改notification-script 和client-reconfig-script 两个脚本。默认禁止如果允许动态修改可能会引发安全问题。动态修改配置当redis-cli 连接上sentinel 后通过sentinel set 命令 可同台修改配置信息比如执行sentinel set mymaster quorum 2sentinel 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节点加入就记录新加入节点的信息并与其建立连接。如果发现有Sentinel Leader 选举的选票信息则执行Leader选举过程。汇总其他Sentinel节点对当前Redis节点在线状态的判断结果作为Redis节点客观下线的判断依据。Redis节点下线判断主观下线每个sentinel 每秒向Redis节点发送心跳检测如果Sentinel在down-after-milliseconds 时间内没收到回复则Sentinel节点对该Redis节点做出“下线”判断。这个判断只是当前Sentinel节点认为的。所以称为主观下线客观下线当sentinel 主观下线的节点是master时该sentinel节点会向其他sentinel节点询问对master节点的判断。其他sentinel 节点会响应0在线或1下线。当sentinel 收到超过quorum 个下线判断后就会对master做出客观下线判断。Sentinel Leader 选举当Sentinel 做出客观下线判断后由Sentinel Leader 来完成后续的故障转移。Leader 选举是通过Raft算法实现。Raft算法大致思路如下每个选举参与者都有当选Leader的资格。 当完成“客观下线”判断后会立即“毛遂自荐”推选自己当选Leader将自己的提案给所有参与者。 其他参与者收到提案后只要手中的选票投出去。就会通过该提案并将同意结果反馈给提案者。 后续再过来的提案会由于参与者没有选票而被拒绝。 当提案者收到同意数量大于maxquorumsentinelNum/2 1时就当选Leader注意网络正常情况下基本谁先做出“客观下线”判断谁就会发起选举谁就会当选Leader选举会在故障转移之前进行。故障转移结束后Leader不再存在。master选择算法过滤主观下线的没有心跳的replica-priority0的Redis节点在剩余Redis节点中选出replica-priority最小的节点列表如果只有一个直接返回。从优先级相同的节点列表中选出复制偏移量最大的节点如果只有一个直接返回。从复制偏移量相同的节点列表中选择动态ID最小的节点返回。故障转移过程sentinel Leader 复制故障转移步骤如下sentinel Leader根据master选择算法选出一个slave作为新的mastersentinel Leader向新master发出slaveof 指令使其晋升为mastersentinel Leader向新master 发送 info replication 指令获取master的动态IDsentinel Leader向其余Redis节点发送消息告知他们新master 的动态IDsentinel Leader向其余Redis节点发送slaveof masterIP masterport指令使他们称为新master的slavesentinel Leader从所有slave 中每次选择parallel-syncs个slave 进行数据同步直到所有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定理CAP定理指在一个分布式系统中一致性 Consistency、可用性 Available、分区容错性 Partition tolerance三者不可兼得。一致性C分布式系统中多个主机之间是否保持数据一致的特性即当数据发生更新操作后每个主机的数据仍然处于一致。可用性A系统提供的服务必须一直处于可用的状态当请求到来能在有效时间内做出响应。分区容错性P分布式系统在遇到网络分区故障时仍能够对外提供服务。由于分布式系统的网络环境不可控因此系统必须具备分区容错性但系统不能同时保证一致性和可用性。即要么CP要么AP。BASE理论BASE 是Basically Available基本可以、Soft state软状态、Eventually consistent最终一致性 三个短语的简写。BASE 是对CAP中一致性和可用性权衡的结果是基于CAP逐步演化而来。BASE 的思想是即使无法做到强一致性但可以根据自身业务特点采用适当方式达到最终一致性。基本可用基本可用指分布式系统在出现不可预知故障时允许损失部分可用性。软状态软状态指数据存在的中间状态认为该中间状态不会影响系统的整体可用性。即允许主机间进行数据同步的过程存在延迟。软状态就是一种灰度状态、过度状态。最终一致性最终一致性强调系统中的所有数据副本在经过一段时间的同步后最终达到一致的状态。最终一致性的本质是保证最终数据达到一致不需要实时一致。CAP的应用Zookeeper : CP 模式保证一致性牺牲可用性。ConsulCP模式保证一致性牺牲可用性。RedisAP模式保证可用性牺牲一致性。
