Redis—哨兵集群—主从切换

Redis哨兵系列文章目录

一、基础
二、常规命令
三、工作原理
四、主从切换

---

---

前言

  我们知道Sentinel能够实现Redis主从的自动切换,在实际工作环境中,我们往往也使用Redis哨兵集群来用于保证Redis服务的高可用。上一篇工作原理也简单介绍了哨兵集群基本工作原理。但实际工作环境中还需要注意哪些？

---

一、背景

  有一次业务发现系统异常，通过检查发现Redis主节点异常后未进行主从切换。检查因为物理机问题，导致多个Sentinel节点和Redis节点服务异常，其中Redis主节点也在异常列表中，但当前还有正常运行的Redis从节点和Sentinel节点，正常Sentinel节点数目刚好等于配置文件中sentinel monitor mymaster IP Port quorum中 quorum的数量，那么为什么会没进行主从切换呢？是Sentinel未生效还是因为其他原因？

二、原因分析

  基本环境是Redis哨兵集群，Sentinel节点数量为5个，因物理机异常，导致其中三个Sentinel停止服务，当前还有2个Sentinel服务运行正常，按照配置文件中设置quorum数量为2，应该是能够正常进行Redis服务主从切换的。

1. Sentinel服务未生效？

  开始怀疑是Sentinel服务异常导致未进行主从切换，但连接sentinel服务执行相关命令查看服务状态返回服务状态正常，

  ...
  +sdown master mymaster ip port 
  +odown master mymaster ip port #quorum 2/2 
  ...

在Sentinel日志中也显示master节点被客观下线了,表明Sentinel服务正常运行，那为什么没有进行主从切换呢?

2. 执行主从切换

  master节点已经被客观下线了，那么为什么没执行主从切换呢？
  查看相关资料后发现，在主节点客观下线后，哨兵执行主从切换也是需要进行选举的，即确定由哪个哨兵执行主从切换的过程。
  最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。
  如果一轮轮投票没有产生 Leader。哨兵集群会等待一段时间 （也就是哨兵故障转移超时时间的 2 倍），再重新选举。这是因为，哨兵集群能够进行成功投票，很大程度上依赖于选举命令的正常网络传播。如果网络压力较大或有短时堵塞， 就可能导致没有一个哨兵能拿到半数以上的赞成票。所以，等到网络拥塞好转之后，再进行投票选举，成功的概率就会增加。
  比如如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得 2 票，而不是 1 票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的，所以通常我们至少会配置 3 个哨兵实例。

3. 失败原因

  所以根据上面相关原因，简单来说是因为存活哨兵数量虽然满足配置的quorum值，但因为无法拿到整个Sentinel集群半数以上的赞成票。即无法选举出执行主从切换的Leader。即：

1. 哨兵集群可以判定主库“主观下线”。由于quorum=2，所以当一个哨兵判断主库“主观下线”后，询问另外一个哨兵后也会得到同样的结果，2个哨兵都判定“主观下线”，达到了quorum的值，因此，哨兵集群可以判定主库为“客观下线”。
2. 但哨兵不能完成主从切换。哨兵标记主库“客观下线后”，在选举“哨兵领导者”时，一个哨兵必须拿到超过多数的选票(5/2+1=3票)。但目前只有2个哨兵活着，无论怎么投票，一个哨兵最多只能拿到2票，永远无法达到多数选票的结果。

三、实际哨兵集群运维经验

1. 哨兵Leader选举

  不同哨兵的网络连接、系统压力不完全一样，接收到下线协商消息的时间也可能不同，所以，它们同时做出主库客观下线判定的概率较小，所以一般都有个先后关系,
  其次，哨兵对主从库进行的在线状态检查等操作，是属于一种时间事件，用一个定时器来完成， 一般来说每100ms执行一次这些事件。每个哨兵的定时器执行周期都会加上一个小小的随机时间 偏移，目的是让每个哨兵执行上述操作的时间能稍微错开些，也是为了避免它们都同时判定主库下线，同时选举Leader。
  最后，即使出现了都投给自己一票的情况，导致无法选出Leader，哨兵会停一段时间（一般是故 障转移超时时间failover_timeout的2倍），然后再可以进行下一轮投票。
  哨兵如果没有给自己投票，就会把票投给第一个给它发送投票请求的哨兵。后续再有投票请求来，哨兵就拒接投票了。

2. down-after-milliseconds设置

  调大down-after-milliseconds值，对减少误判是不是有好处？是有好处的，适当调大down-after-milliseconds值，当哨兵与主库之间网络存在短时波动时，可以降低误判的概率。但是调大down-after-milliseconds值也意味着主从切换的时间会变长，对业务的影响时间越久，我们需要根据实际场景进行权衡，设置合理的阈值。

3. 哨兵实例数量多少

  哨兵实例越多，误判率会越低，但是在判定主库下线和选举 Leader 时，实例需要拿到的赞成票数也越多，等待所有哨兵投完票的时间可能也会相应增加，主从库切换的时间也会变长，客户端容易堆积较多的请求操作，可能会导致客户端请求溢出，从而造成请求丢失。 如果业务层对 Redis 的操作有响应时间要求，就可能会因为新主库一直没有选定，新操作无法执行而发生超时报警。
  哨兵在判定“主观下线”和选举“哨兵领导者”时，都需要和其他节点进行通信，交换信息，哨兵实例越多，通信的次数也就越多，而且部署多个哨兵时，会分布在不同机器上，节点越多带来的机器故障风险也会越大，这些问题都会影响到哨兵的通信和选举，出问题时也就意味着选举时间会变长，切换主从的时间变久。
  所以哨兵数量并不是越多越好。可以根据实际环境来进行规划，常规小规模集群其实设置3个节点即可。

总结

  以上就是关于Redis Sentinel集群关于主从切换相关的基本原理，有任何相关问题，欢迎留言讨论。