Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
79224 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

08 | 哨兵集群:哨兵挂了,主从库还能切换吗?

你好,我是蒋德钧。
上节课,我们学习了哨兵机制,它可以实现主从库的自动切换。通过部署多个实例,就形成了一个哨兵集群。哨兵集群中的多个实例共同判断,可以降低对主库下线的误判率。
但是,我们还是要考虑一个问题:如果有哨兵实例在运行时发生了故障,主从库还能正常切换吗?
实际上,一旦多个实例组成了哨兵集群,即使有哨兵实例出现故障挂掉了,其他哨兵还能继续协作完成主从库切换的工作,包括判定主库是不是处于下线状态,选择新主库,以及通知从库和客户端。
如果你部署过哨兵集群的话就会知道,在配置哨兵的信息时,我们只需要用到下面的这个配置项,设置主库的 IP端口,并没有配置其他哨兵的连接信息。
sentinel monitor <master-name> <ip> <redis-port> <quorum>
这些哨兵实例既然都不知道彼此的地址,又是怎么组成集群的呢?要弄明白这个问题,我们就需要学习一下哨兵集群的组成和运行机制了。

基于 pub/sub 机制的哨兵集群组成

哨兵实例之间可以相互发现,要归功于 Redis 提供的 pub/sub 机制,也就是发布 / 订阅机制。
哨兵只要和主库建立起了连接,就可以在主库上发布消息了,比如说发布它自己的连接信息(IP 和端口)。同时,它也可以从主库上订阅消息,获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的 IP 地址和端口。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(116)

  • 最新
  • 精选
  • 小喵喵
    置顶
    老师请教下: 1、图示哨兵选举过程中,选举的结果取决于S2的投票,如果S2也投给自己,并且每轮投票都是只投给自己,岂不是无法选出“Leader”,是不是这个过程从了死循环呢? 2、投票投给谁,依据是什么?

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

    19
    173
  • Kaito
    Redis 1主4从,5个哨兵,哨兵配置quorum为2,如果3个哨兵故障,当主库宕机时,哨兵能否判断主库“客观下线”?能否自动切换? 经过实际测试,我的结论如下: 1、哨兵集群可以判定主库“主观下线”。由于quorum=2,所以当一个哨兵判断主库“主观下线”后,询问另外一个哨兵后也会得到同样的结果,2个哨兵都判定“主观下线”,达到了quorum的值,因此,哨兵集群可以判定主库为“客观下线”。 2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”,在选举“哨兵领导者”时,一个哨兵必须拿到超过多数的选票(5/2+1=3票)。但目前只有2个哨兵活着,无论怎么投票,一个哨兵最多只能拿到2票,永远无法达到多数选票的结果。 但是投票选举过程的细节并不是大家认为的:每个哨兵各自1票,这个情况是不一定的。下面具体说一下: 场景a:哨兵A先判定主库“主观下线”,然后马上询问哨兵B(注意,此时哨兵B只是被动接受询问,并没有去询问哨兵A,也就是它还没有进入判定“客观下线”的流程),哨兵B回复主库已“主观下线”,达到quorum=2后哨兵A此时可以判定主库“客观下线”。此时,哨兵A马上可以向其他哨兵发起成为“哨兵领导者”的投票,哨兵B收到投票请求后,由于自己还没有询问哨兵A进入判定“客观下线”的流程,所以哨兵B是可以给哨兵A投票确认的,这样哨兵A就已经拿到2票了。等稍后哨兵B也判定“主观下线”后想成为领导者时,因为它已经给别人投过票了,所以这一轮自己就不能再成为领导者了。 场景b:哨兵A和哨兵B同时判定主库“主观下线”,然后同时询问对方后都得到可以“客观下线”的结论,此时它们各自给自己投上1票后,然后向其他哨兵发起投票请求,但是因为各自都给自己投过票了,因此各自都拒绝了对方的投票请求,这样2个哨兵各自持有1票。 场景a是1个哨兵拿到2票,场景b是2个哨兵各自有1票,这2种情况都不满足大多数选票(3票)的结果,因此无法完成主从切换。 经过测试发现,场景b发生的概率非常小,只有2个哨兵同时进入判定“主观下线”的流程时才可以发生。我测试几次后发现,都是复现的场景a。 哨兵实例是不是越多越好? 并不是,我们也看到了,哨兵在判定“主观下线”和选举“哨兵领导者”时,都需要和其他节点进行通信,交换信息,哨兵实例越多,通信的次数也就越多,而且部署多个哨兵时,会分布在不同机器上,节点越多带来的机器故障风险也会越大,这些问题都会影响到哨兵的通信和选举,出问题时也就意味着选举时间会变长,切换主从的时间变久。 调大down-after-milliseconds值,对减少误判是不是有好处? 是有好处的,适当调大down-after-milliseconds值,当哨兵与主库之间网络存在短时波动时,可以降低误判的概率。但是调大down-after-milliseconds值也意味着主从切换的时间会变长,对业务的影响时间越久,我们需要根据实际场景进行权衡,设置合理的阈值。

    作者回复: Kaito同学的答题一如既往的精彩!

    87
    887
  • 这篇文章太好了,直接解决了一个困惑我很久的问题,我一直把判断下线和选主主当成了同一件事,把quorum当成是判断下线和选举leader的阀值,原来判断下线还选主是两个分开的事情

    作者回复: 有帮助就好 :D

    4
    20
  • 范闲
    哨兵判断下线分为可能下线和确定下线两种状态。 在课后的例子中,5个哨兵正常2个,异常3个,qurum为2(判断确定下线的哨兵数目) 根据主从选举要求必须半数以上的节点同意,即要求数量大于N/2+1。此例中是5/2+1=3,而只有2个哨兵活着因此不可能完成主从切换。 而确定下线的数目为2,2个哨兵可以完成确定下线的判断。

    作者回复: 理解到位了! 不过,一般我们还是叫主观下线和客观下线更多些。。

    2
    3
  • riryoutexi
    整个哨兵集群都挂了,还会主从切换吗

    作者回复: 哨兵都挂了,无能为力了。。。

    4
    2
  • 注定非凡
    一,作者讲了什么? 哨兵集群的工作机制 二,作者是怎么把这事给讲明白的? 1,哨兵之间互通机制:基于pub/sub机制,在主库中有一个"__sentinel__:hello"的频道,哨兵之间互相发现通信 2,哨兵与主从库互通机制:哨兵向主库发送INFO指令,可以获取所有从库的信息,实现对主库,从库的监控 3,哨兵判定主库异常机制:哨兵集群中任意一个实例都可以发起主库异常“投票仲裁”流程 三,为了讲明白,作者都讲了哪些要点?有哪些亮点? 1,亮点1:哨兵之间的互动是通过发布订阅机制完成的,利用自身的特性来实现。这让我联想到kafka对于日息位置偏移量的管理 2,要点1:哨兵之间通信不是哨兵之间之间联系,而是通过订阅主库的同一频道来获取彼此的信息 3,要点2:哨兵是通过INFO指令,从主库获取从库信息,并与每个从库建立连接,监控所有主从库状态 4,要点3:哨兵是一个特殊的redis实例,所以客户端可以订阅哨兵的指定频道获得redis主从库的信息 5,要点4:哨兵集群执行主从切换机制:谁发现,谁就发起投票流程,谁获得多数票,谁就是哨兵Leader,由Leader负责主从库切换 6,要点5:哨兵集群Leader选举成功与否,依赖于网络通信状况,网络拥塞会导致选举失败,重新进行新一轮选举 四,对于作者所讲,我有哪些发散性思考? 五,在未来的哪些场景里,我可以使用它? 六,留言区的收获:(感谢 @ 小喵喵 的提问) 1,哨兵投票机制: a:哨兵实例只有在自己判定主库下线时,才会给自己投票,而其他的哨兵实例会把票投给第一个来要票的请求,其后的都拒绝 b:如果出现多个哨兵同时发现主库下线并给自己投票,导致投票选举失败,就会触发新一轮投票,直至成功 2,哨兵Leader切换主从库的机制:(感谢 @Kaito ,@Darren 大神的解答) 哨兵成为Leader的必要条件:a:获得半数以上的票数,b:得到的票数要达到配置的quorum阀值 主从切换只能由Leader执行,而成为Leader有两个必要的条件,所以当哨兵集群中实例异常过多时,会导致主从库无法切换
    10
    104
  • Darren
    1、可以正确的判断主库“客观下线”,以为其中一个哨兵已经获得了“客观下线”所需要的投票数; 2、不能进行自动的主从切换,因为在主从切换的时候,必须选择出一个主哨兵,但是选择主哨兵有2个条件: 2.1 拿到半数以上的赞成票; 2.2 拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。 此时可以满足投票数,但是拿不到半数以上的投票,因此无法选出主哨兵,所以无法进行主从切换。 3、哨兵的实例不是越多越好,因为哨兵的选举使用的是Raft协议,这个协议是Paxos协议的变种,这种协议在选主时,需要所有的节点参与投票,所以节点越多,选举耗时可能就会更久,所以根据对服务SLA的要求,评估一个节点可能出现问题的概率,选择合适的哨兵数量。 4、down-after-milliseconds不是越大越好的,虽然可以减少误判的概率,但是问题真正发生时,服务的不可用状态也会更久,所以down-after-milliseconds要根据真实的业务场景,进行取舍。
    4
    25
  • 悟空聊架构
    选举leader的过程和分布式Raft协议很像。之前写过一篇介绍Raft机制的文章,可以看看:《用动图讲解分布式Raft》https://mp.weixin.qq.com/s/US12ux7osqH_L0CtQyw-9A
    18
  • 一步
    在哨兵节点选取Leader 节点的时候,某个节点已经投出了 Y 票,但是该轮没有选举出来Leader, 这时候这个节点怎么知道已经到了下一轮需要继续投票了呢? 也可以这样问:一个节点在一轮只能投出一个票,但是这个节点怎么知道一轮什么时候,什么时候结束的呢?
    3
    8
  • 可怜大灰狼
    老师你好。看到“同时,哨兵又通过 INFO 命令,获得了从库连接信息,也能和从库建立连接,并进行监控了”这句话。我翻了一下代码sentinel.c/sentinelSendPeriodicCommands。发现sentinelSendPeriodicCommands里有一行代码: redisAsyncCommand(ri->cc, sentinelInfoReplyCallback, NULL, "INFO"); 的确哨兵也是会往从库发送INFO命令的,而从库的INFO返回值中,我发现包含以下的内容: run_id:d7e50cc730c3851fcb9d8b4b6af425f59e5207a6 slave_repl_offset:140354728 slave_priority:100 07节里说的三轮打分,是不是根据从库INFO监控信息来进行打分的?也就是说,第一轮根据slave_priority,第二轮根据slave_repl_offset,第三轮根据run_id。感觉和前面内容串起来了。 不对的地方,麻烦老师纠错下。
    6
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部