RocketMQ高可用架构原理

浅浅的花香味﹌ 2023-07-19 10:37 176阅读 0赞

RocketMQ要保证高可用的话，可以使用主从架构，也就是将Broker分为Master Broker和Slave Broker，下面文章中的Master和Slave分别指的是Master Broker和Slave Broker

与其他传统的主从架构一样，Master负责接收数据之后，再将数据同步给Slave，Master和Slave都会向NameServer注册路由信息，同时每隔30秒发送一次心跳。RocketMQ主从架构数据同步采用的是Pull模式，Slave不停的发送请求到Master上去拉取消息  
与其他传统的主从架构不一样的是，RocketMQ的主从架构并不是纯粹的读写分离。写的话还是依靠Master，而读的话，既可能是从Master读，也可能是从Slave读，这取决于Master

读消息的时候，第一次是从Master上去读的，之后是去Master还是Slave上读消息，是由Master根据自身的负载情况和Slave的数据同步情况来向消费者建议。如果Master的写负载已经很高的话，那么就会建议消费者下次拉取消息的话就去Slave上拉取；如果Slave数据同步较慢，还没有完全同步Master的消息的话，那么下一次还是会来Master上拉取消息

当Master节点宕机之后，一般来说会对Slave节点进行选举然后选出新的Master继续提供服务。但是在RocketMQ 4.5版本之前，还不支持自动故障切换，需要手工调整才能完成  
在RocketMQ 4.5版本之后，引入了Dledger技术，是基于Raft协议实现的（如果不清楚Raft协议可以参考一下这个[链接][Link 1]）。DLedger引入之后，可以让一个Master对应多个Slave，也就是存在多个副本，一旦Master宕机了，多个Slave之间就会通过DLedger技术和Raft协议算法进行选举，选出来的Slave节点就作为新的Master继续提供服务。

那么DLedger技术的原理是什么呢？  
其实DLedger只做一件事情，就是CommitLog，DLedger可以让我们忽略其他的东西，直接关注CommitLog即可。CommitLog在RocketMQ中就是持久化的消息，所以**使用DLedger技术其实就是让DLedger来替代RocketMQ的Broker管理CommitLog**，然后Broker还是可以基于DLedger管理的CommitLog去构建出来机器上的各个ConsumerQueue磁盘文件

绕来绕去可能有点晕，来理一下里面的因果关系。首先DLedger技术可以基于Raft协议来进行选主，其次将RocketMQ的CommitLog交给DLedger来管理，那么在Master宕机的时候，DLedger就可以自己进行选举，然后把选举的结果交给RocketMQ的Broker，下次通过NameServer获取路由信息的时候就可以直接找到新的Master，从而完成自动故障切换

讲完了DLedger的基本原理，接下来来看看选举的机制到底是什么样的  
DLedger是基于Raft协议来进行选主的，大致流程为：  
当Leader宕机，我们假设此时有3个Follower，分别为Broker1、Broker2、Broker3，此时他们都没有接收到其他人的投票，所以此时都会投给自己，这一轮无法选出新的Leader，接下来所有的Follower随机休眠一段时间，比如依次休眠1s、2s、3s，优先苏醒的Broker1还会投票给自己，然后将投票信息发送给其他的节点，此时Broker2苏醒，接收到了Broker1的投票信息，就会尊重他的决定，也给Broker1投票，接着Broker3苏醒之后，也是一样的给Broker1投票，此时Broker1就获得了大多数节点的支持，当有一个节点获得了（N / 2） + 1个，也就是大多数节点的支持之后，就能成功当选  
上面的那个步骤，反复几次之后，一定是可以选出新的Leader的

最后来说说DLedger如何基于Raft协议进行多副本同步  
DLedger多副本数据同步，Leader Broker收到一条消息，通过DledgerServer组件发送一个uncommited消息给Follow Broker的DledgerServer，Follower接收到消息之后发送一个ack确认消息给Leader，多数Follower都确认之后，Leader再发送一个commited消息到Follower上，Follower将接收到的消息置为commited，此时就完成了数据同步

一张图总结一下  
![RocketMQ高可用架构][RocketMQ]

[Link 1]: http://thesecretlivesofdata.com/raft/
[RocketMQ]: /images/20230528/930ec5faeb164d50b0d40058edb85f99.png

发表评论取消回复

表情：

评论列表（有 0 条评论，176人围观）

还没有评论，来说两句吧...

相关阅读

相关 mysql高可用架构

高可用高可用(High Availabiltity) * 应用提供持续不间断(可用)的服务的能力 * 系统高可用性的评价通常用可用率表示 ![20190...

亦凉/ 2024年04月19日 16:02/ 0 赞/ 105 阅读

相关 RocketMQ高可用架构原理

RocketMQ要保证高可用的话，可以使用主从架构，也就是将Broker分为Master Broker和Slave Broker，下面文章中的Master和Slave分别指的是

浅浅的花香味﹌/ 2023年07月19日 10:37/ 0 赞/ 177 阅读

相关【RocketMQ 高可用】RocketMQ 高可用系列

目录一、消息存储机制 1.1 介绍 1.2 存储介质类型和对比 1.3 消息存储机制 1.3.1 概述 1.3.2 顺序读写和随机读写对于机械硬盘来说为什么性能差

妖狐艹你老母/ 2023年02月25日 13:24/ 0 赞/ 36 阅读

相关 RocketMQ架构及原理

RocketMQ源于阿里，原名MetaQ，后捐献给apache，支持Java、C/C++、Python、Go；是一款分布式、队列模型的开源消息中间件，经历了几年淘宝双十一的考验

亦凉/ 2023年01月23日 03:56/ 0 赞/ 266 阅读

相关网站高可用架构

可用性就是系统在发生故障的时候，可以继续提供服务的能力。高可用性，就是故障发生时，系统可以在很短的时间内就能恢复正常服务，甚至外部根本没有察觉。提高可用性，核心手段在于冗余

Bertha 。/ 2022年10月29日 03:19/ 0 赞/ 74 阅读

相关同程旅行基于 RocketMQ 高可用架构实践

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ub

冷不防/ 2022年10月11日 14:54/ 0 赞/ 301 阅读

相关 12 RocketMQ高可用的生产部署架构

1.NameServer采用集群化部署，保证高可用第一步，让NameServer集群化部署，初步可以部署在三台机器上，可以充分保证NameServer作为路由中心的可用

太过爱你忘了你带给我的痛/ 2022年10月08日 05:53/ 0 赞/ 311 阅读

相关高可用架构方案

1、高可用架构具备特征 1、主从切换或双机双工 1）主从切换，是当其中一台机器的服务宕机后，对于调用者来说，能够迅速的切换到其他可用服务，从服务升级为主服务，这种切

向右看齐/ 2022年10月05日 01:52/ 0 赞/ 274 阅读

相关 Redis高可用原理

转载：https://blog.csdn.net/hellozhxy/article/details/91387166 Redis 是被广泛使用的基础软件之一，对于架构

末蓝、/ 2022年01月19日 00:25/ 0 赞/ 257 阅读

相关 Mysql高可用架构

一，什么是高可用高可用性H.A. ( High Availability )指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间，以提高系

叁歲伎倆/ 2021年09月21日 06:20/ 0 赞/ 465 阅读