Redis--哨兵机制与CAP定理

哨兵机制

对于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.conf

• sentinel monitor

指定sentinel要监控的master是谁【ip port】，并为master起名。该名称会在后面的配置中使用。

同时指定sentinel集群中决定master 宕机判断的 quorum 数量。

quorum的另一个作用是：在sentinel的Leader选举时，至少要有max（quorum，sentinelNum/2 + 1）个sentinel参与，选举才能进行。

这里需要注释掉这个配置，因为要在后面的其他配置文件中设置。

• sentinel auth-pass

如果master主机设置了访问密码，该属性指定master的主机名与访问密码。

• 新建sentinel26380.conf、sentinel26381.conf、sentinel26382.conf

在cluster目录下新建这三个文件作为Sentinel的配置文件

Redis高可用集群启动

1. 先启动三个Redis，并设置主从关系（可以在slave的配置文件里设置replicaof 192.168.1.100 6379 来设置为他的slave，避免每次启动后都要输入命令，这种方式不用输入命令就直接设置好主从关系了。）

2. 启动Sentinel集群。

   首先，redis-server 和redis-sentinel 命令本质上是同一个命令。

   之所以可以启动不同的进程，是因为启动时所加载的配置文件不同。所以在启动Sentinel时，要指定sentinel.conf文件。

3. 两种启动方式：redis-sentinel sentinel26380.conf 或者 redis-server sentinel26380.conf --sentinel

4. 启动三台sentinel后，可以通过info sentinel 查看基本信息。

5. 启动之后，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分钟。该超时时间的用途有：

1. 当第一次故障转移失败，在同一个master上进行第二次故障转移尝试的时间为该时间的2倍。
2. 新master晋升完毕，slave从老master强制转到新master进行数据同步的时间阈值。
3. 取小正在进行的故障转移所需时间的阈值。
4. 新master晋升完毕，所有replicas 的配置文件更新为新master的时间阈值。

• sentinel deny-scripts-reconfig

指定是否可以通过命令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节点收到主题信息后，会读取并解析这些信息，然后完成以下工作：

  1. 如果发现有新的Sentinel节点加入，就记录新加入节点的信息，并与其建立连接。
  2. 如果发现有Sentinel Leader 选举的选票信息，则执行Leader选举过程。
  3. 汇总其他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，将自己的提案给所有参与者。
其他参与者收到提案后，只要手中的选票投出去。就会通过该提案并将同意结果反馈给提案者。
后续再过来的提案会由于参与者没有选票而被拒绝。
当提案者收到同意数量大于max（quorum，sentinelNum/2 +1）时，就当选Leader

注意：

• 网络正常情况下，基本谁先做出"客观下线"判断，谁就会发起选举，谁就会当选Leader
• 选举会在故障转移之前进行。
• 故障转移结束后，Leader不再存在。

master选择算法

1. 过滤主观下线的，没有心跳的，replica-priority=0的Redis节点
2. 在剩余Redis节点中选出replica-priority最小的节点列表，如果只有一个，直接返回。
3. 从优先级相同的节点列表中选出复制偏移量最大的节点，如果只有一个，直接返回。
4. 从复制偏移量相同的节点列表中选择动态ID最小的节点返回。

故障转移过程

sentinel Leader 复制故障转移，步骤如下：

1. sentinel Leader根据master选择算法，选出一个slave作为新的master
2. sentinel Leader向新master发出slaveof 指令，使其晋升为master
3. sentinel Leader向新master 发送 info replication 指令，获取master的动态ID
4. sentinel Leader向其余Redis节点发送消息，告知他们新master 的动态ID
5. sentinel Leader向其余Redis节点发送 slaveof <masterIP> <masterport> 指令，使他们称为新master的slave
6. sentinel Leader从所有slave 中每次选择parallel-syncs个slave 进行数据同步，直到所有slave全部同步完毕。
7. 故障转移完毕。

节点上线

不同类型的节点上线方式不同

• 原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 模式，保证一致性，牺牲可用性。
• Consul：CP模式，保证一致性，牺牲可用性。
• Redis：AP模式，保证可用性，牺牲一致性。
• Nacos：当作注册中心时，默认AP。也支持CP模式。