Redis 哨兵机制 Sentinel

Redis 哨兵机制 Sentinel

提示：之前我们讲了 Redis 复制的主要内容，但 Redis 复制有一个缺点，当主机 Master 宕机以后，我们需要人工解决切换，比如使用 slaveof no one 。实际上主从复制 并没有实现高可用。

---

---

前言

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

---

一、Sentinel 哨兵机制的原理

Redis Sentinel 基于分布式架构实现。多个Sentinel和Redis主从节点。每个Sentinel会对每个Redis节点和其余的Sentinel进行监控，当它发现节点不可达时，会对节点做下线标识。

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

基本的故障转移：

1. 主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
2. 每个 Sentinel 节点通过定期监控发现主节点出现了故障
3. 多个 Sentinel 节点对主节点的故障达成一致会选举出其中一个节点作为领导者负责故障转移
4. Sentinel 领导者节点执行了故障转移，整个过程基本是跟我们手动调整一致的，只不过是自动化完成的。
5. 故障转移后整个 Redis Sentinel 的结构,重新选举了新的主节点

二、Sentinel 哨兵机制的准备

1.资料准备

这里准备了一个6个文件夹和一个compose文件（避免一个个的去部署启动，为了减少重复性的工作和增加效率）。资料下载地址

2.部署情况

---

三、Sentinel 的核心配置：

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

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

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

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

5. List item

四、Sentinel 哨兵机制的常见问题

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

2、集群脑裂导致数据丢失 脑裂，也就是说，某个master所在机 器突然脱离了正常的网络，跟其它slave机器不能连接，但是实际上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 多少秒。

---