Redis Sentinel 架构原理详解(四)

前言

前面Redis Sentinel 架构原理详解(三)中介绍了redis哨兵集群中sentinel的leader如何选举，以及redis主从中的新master如何选择，这里再和大家一起学习下Sentinel集群的quorum 和majority，configuration epoch，以及Redis Sentinel可能出现的问题以及解决办法。

Sentinel集群的quorum和majority

quorum 是在 sentinel.conf中手动配置的，默认为2，意味着只有大于等于quorum数量的sentinel都认为master主观下线，sentinel集群才会认为master客观下线。

# sentinel monitor [master-name] [master-ip] [master-port] [quorum] 
sentinel monitor mymaster 127.0.0.1 6379 2

sentinel集群执行故障转移时需要选举leader，此时涉及到majority，majority 代表 sentinel 集群中大部分 sentinel 节点的个数，只有大于等于 max(quorum, majority) 个节点给某个 sentinel 节点投票，才能确定该sentinel节点为leader，majority 的计算方式为：num(sentinels) / 2 + 1，比如：

2 个节点的 sentinel 集群的 majority为 2
3 个节点的 sentinel 集群的 majority为 2
4 个节点的 sentinel 集群的 majority为 3
5 个节点的 sentinel 集群的 majority为 3

所以 sentinel集群的节点个数至少为3个，当节点数为2时，假如一个 sentinel 节点宕机，那么剩余一个节点是无法让自己成为 leader 的，因为2个节点的sentinel 集群的 majority是2，此时没有2个节点都给剩余的节点投票，也就无法选择出leader，从而无法进行故障转移。另外最好把quorum的值设置为 <= majority，否则即使 sentinel 集群剩余的节点满足majority数，但是有可能不能满足quorum数，那还是无法选举leader，也就不能进行故障转移。

configuration epoch

configuration epoch 是当前redis主从架构的配置版本号，无论是sentinel集群选举 leader 还是进行故障转移的时候，要求各 sentinel节点得到的 configuration epoch都是相同的，sentinel is-master-down-by-addr 命令中就必须有当前配置版本号这个参数，在选举leader过程中，如果本次选举失败，那么进行下一次选举，就会更新配置版本号，也就是说，每次选举都对应一个新的 configuration epoch，在故障转移的过程中，也要求各个 sentinel 节点使用相同的 configuration epoch。在故障转移成功之后，sentinel leader 会更新生成最新的master 配置，configuration epoch 也会更新，然后同步给其他的 sentinel 节点，这样保证 sentinel 集群中保存的 master、slave 配置都是最新的，当 client 请求的时候就会拿到最新的配置信息。

Redis Sentinel可能出现的问题

redis sentinel 无法保证数据完全不丢失，原因有两个：

• 异步复制导致的数据丢失     因为 master -> slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。
•  redis 服务脑裂导致的数据丢失    脑裂，也就是说，某个master所在机器突然网络故障，跟其他 slave 机器不能连接，但是实际上master还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂。此时虽然某个 slave 被切换成了 master，但是 client 还没来得及切换到新的master，还继续写向旧 master 的数据就丢失了。因为旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。

redis 提供了两个配置参数可以尽量丢失少的数据：

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

第一个参数表示 master必须至少有一个 slave在进行正常复制，否则就拒绝写请求，此时 master 丧失可用性。何为正常复制，何为异常复制？这个就是由第二个参数控制的，它的单位是秒，表示如果 10s 没有收到从节点的反馈，就意味着从节点同步不正常。这样可以把 master 宕机期间的数据丢失降低到可控范围内。

redis-2.6 版本提供的是 redis sentinel v1版本，但是功能性和健壮性都有一些问题，如果想使用redis sentinel的话，建议使用2.8以上版本，也就是v2版本的 redis sentinel。

总结

这里和大家一起学习了sentinel集群中的quorum和majority参数的具体配置意义，以及configuration epoch版本号配置。redis哨兵不能保证数据绝对不丢失，在主从异步复制过程数据没有及时同步，或因为网络因素导致选举新的master节点而产生脑裂等问题。所以在选用redis哨兵实现高可用的时候需要考虑这些问题，如何将风险降低到最小。