Redis-哨兵机制详解

1. 主从复制的问题

我们讲了Redis复制的主要内容，但Redis复制有一个缺点，当主机Master宕机以后，我们需要人工解决切换，比如使用slaveof no one。实际上主从复制并没有实现高可用。
高可用侧重备份机器， 利用集群中系统的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务

如下图所示：

一旦主节点宕机，写服务无法使用，就需要手动去切换，重新选取主节点，手动设置主从关系。

那么如何解决呢？

如果我们有一个监控程序能够监控各个机器的状态及时作出调整，将手动的操作变成自动的。Sentinel的出现就是为了解决这个问题

2. 哨兵机制的原理及实现

Redis Sentinel一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余
Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

基本的故障转移流程：

1. 主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败

2. 每个 Sentinel 节点通过定期监控发现主节点出现了故障

3. 多个 Sentinel 节点对主节点的故障达成一致会选举出其中一个节点作为领导者负责故障转移
4. Sentinel 领导者节点执行了故障转移，整个过程基本是跟我们手动调整一致的，只不过是自动化完成的
5. 故障转移后整个 Redis Sentinel 的结构,重新选举了新的主节点

并且Redis Sentinel 具有以下几个功能：

• 监控：Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达
• 通知：Sentinel 节点会将故障转移的结果通知给应用方
• 主节点故障转移： 实现从节点晋升为主节点并维护后续正确的主从关系

• 配置提供者：在 Redis Sentinel 结构中，客户端在初始化的时候连接的是 Sentinel 节点集合 ，从中获取主节点信息。同时Redis Sentinel包含了若个Sentinel节点，这样做也带来了两个好处：

• 对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判。

• Sentinel 节点集合是由若干个 Sentinel 节点组成的，这样即使个别 Sentinel 节点不可用，整个 Sentinel 节点集合依然是健壮的。但是 Sentinel 节点本身就是独立的 Redis 节点，只不过它们有一些特殊，它们不存储数据，只支持部分命令

通过docker-compose构建好哨兵跟主从的环境

sentinel monitor mymaster 127.0.0.1 7000 2

监控的主节点的名字、IP 和端口，最后一个2的意思是有几台 Sentinel 发现有问题，就会发生故障转移，例如 配置为2，代表至少有2个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为 Sentinel 节点的一半加1

注意：最后的参数不得大于sentinel的数量

sentinel down-after-millseconds mymaster 30000

这个是超时的时间（单位为毫秒）。打个比方，当你去ping一个机器的时候，多长时间后仍ping不通，那么就认为它是有问题

sentinel parallel-syncs mymaster 1

当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出Sentinel属于并发还是串行。1代表每次只能复制一个，可以减轻Master的压力；

sentinel auth-pass <master-name> <password>

如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。

sentinel failover-timeout mymaster 180000

表示故障转移的时间。

Sentinel命令

sentinel支持的合法命令如下：

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 failover <master name> 强制sentinel执行failover，并且不需要得到其他sentinel的同意。 但是failover后会将最新的配置发送给其他sentinel。

修改配置

SENTINEL monitor test 127.0.0.1 6379 2 #添加新的监听SENTINEL REMOVE test #放弃对某个master监听SENTINEL set failover-timeout mymaster 180000 #设置配置选项

应用端调用

Master可能会因为某些情况宕机了，如果在客户端是固定一个地址去访问，肯定是不合理的，所以客户端请求是请求哨兵，从哨兵获取主机地址的信息，或者是从机的信息。可以实现一个例子

1、随机选择一个哨兵连接，获取主机、从机信息2、模拟客户端定时访问，实现简单轮训效果，轮训从节点3、连接失败重试访问

Sentinel 实现原理

讲完了Sentinel的代码实现，很多人对Sentinel还不懂其原理。那么接下来我们就来看下Sentinel的实现原理，主要分为以下三个步骤。

1.检测问题，主要讲的是三个定时任务，这三个内部的执行任务可以保证出现问题马上让 Sentinel 知道。2.发现问题，主要讲的是主观下线和客观下线。当有一台 Sentinel 机器发现问题时，它就会主观对它主观下线。 但是当多个 Sentinel 都发现有问题的时候，才会出现客观下线。 3.找到解决问题的人，主要讲的是领导者选举，如何在 Sentinel 内部多台节点做领导者选举，选出一个领导者。4.解决问题，主要讲的是故障转移，即如何进行故障转移。

三个定时任务

首先要讲的是内部Sentinel会执行以下三个定时任务。

• 每10秒每个Sentinel对Master和Slave执行一次Info Replication。

• 每2秒每个Sentinel通过Master节点的channel交换信息（pub/sub）。

• 每1秒每个Sentinel对其他Sentinel和Redis执行ping。

  第一个定时任务，指的是Redis Sentinel可以对Redis节点做失败判断和故障转移，在Redis内部有三个定时任务作为基础，来Info Replication发现Slave节点，这个命令可以确定主从关系。

  第两个定时任务，类似于发布订阅，Sentinel会对主从关系进行判定，通过_sentinel_:hello频道交互。了解主从关系可以帮助更好的自动化操作Redis。然后Sentinel会告知系统消息给其它Sentinel节点，最终达到共识，同时Sentinel节点能够互相感知到对方。

  第三个定时任务，指的是对每个节点和其它Sentinel进行心跳检测，它是失败判定的依据。

主观下线和客观下线

我们先来回顾一下 Sentinel 的配置

sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 30000

那么什么是主观下线呢？

每个Sentinel节点对Redis节点失败的“偏见”。之所以是偏见，只是因为某一台机器30秒内没有得到回复

那么如何做到客观下线呢？

这个时候需要所有Sentinel节点都发现它30秒内无回复，才会达到共识

领导者选举方式

• 每个做主观下线的sentinel节点，会向其他的sentinel节点发送命令，要求将它设置成为领导者
• 收到命令sentinel节点，如果没有同意通过其它节点发送的命令，那么就会同意请求，否则就会拒绝
• 如果sentinel节点发现自己票数超过半数，同时也超过了sentinel monitor mymaster 127.0.0.1 6379 2超过2个的时候，就会成为领导者
• 进行故障转移操作

如何选择“合适的”Slave 节点作为备选主节点

Redis 内部其实是有一个优先级配置的，在配置文件中 slave-priority，这个参数是Salve节点的优先级配置，如果存在则返回，如果不存在则继续。

当上面这个优先级不满足的时候，Redis 还会选择复制偏移量最大的 Slave节点，如果存在则返回，如果不存在则继续。之所以选择偏移量最大，这是因为偏移量越小，和 Master 的数据越不接近，现在 Master挂掉了，说明这个偏移量小的机器数据也可能存在问题，这就是为什么要选偏移量最大的Slave的原因。

如果发现偏移量都一样，这个时候Redis会默认选择runid最小的节点。

生产环境中部署技巧

Sentinel 节点不应该部署在一台物理“机器”上。

这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现Sentinel节点集合真正的高可用，请勿将Sentinel节点部署在同一台物理机器上。

部署至少三个且奇数个的 Sentinel 节点。

个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点。奇数个节点可以在满足该条件的基础上节省一个节点。

3. 哨兵机制的问题及解决

哨兵集群在发现master node挂掉后会进行故障转移，也就是启动其中一个slave node为master node。在这过程中，可能会导致数据丢失的情况。

1. 异步复制导致数据丢失

  因为master->slave的复制是异步，所以可能有部分还没来得及复制到slave就宕机了，此时这些部分数据就丢失了。

1. 集群脑裂导致数据丢失

  脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其它slave机器不能连接，但是实际上master还运行着。

此时哨兵可能就会认为master宕机了，然后开始选举，将其它slave切换成master。这时候集群里就会有2个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换成新的master，还继续写向旧的master的数据可能就丢失了。

因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会被清空，重新从新的master复制数据。

怎么解决？

min-slaves-to-write 1 min-slaves-max-lag 10

要求至少有1个slave，数据复制和同步的延迟不能超过10秒
如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

上面两个配置可以减少异步复制和脑裂导致的数据丢失

1、异步复制导致的数据丢失

在异步复制的过程当中，通过min-slaves-max-lag这个配置，就可以确保的说，一旦slave复制数据和ack延迟时间太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样就可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低到可控范围内

2、集群脑裂导致的数据丢失

集群脑裂因为client还没来得及切换成新的master，还继续写向旧的master的数据可能就丢失了通过min-slaves-to-write确保必须是有多少个从节点连接，并且延迟时间小于min-slaves-max-lag多少秒。

当然对于客户端需要怎么做呢？

对于client来讲，就需要做些处理，比如先将数据缓存到内存当中，然后过一段时间处理，或者连接失败，接收到错误切换新的master处理。