RocketMQ 源码分析(三) —— 高可用

  1. 概述

    本文主要解析 Namesrv、Broker 如何实现高可用,Producer、Consumer 怎么与它们通信保证高可用。

  2. Namesrv 高可用

    启动多个 Namesrv 实现高可用。

    相较于 Zookeeper、Consul、Etcd 等,Namesrv 是一个超轻量级的注册中心,提供命名服务。

2.1 Broker 注册到 Namesrv

?? 多个 Namesrv 之间,没有任何关系(不存在类似 Zookeeper 的 Leader/Follower 等角色),不进行通信与数据同步。通过 Broker 循环注册多个 Namesrv。

···

1: // ??????【BrokerOuterAPI.java】

2: public RegisterBrokerResult registerBrokerAll(

3: final String clusterName,

4: final String brokerAddr,

5: final String brokerName,

6: final long brokerId,

7: final String haServerAddr,

8: final TopicConfigSerializeWrapper topicConfigWrapper,

9: final List

···

2.2 Producer、Consumer 访问 Namesrv

···

1: // ??????【NettyRemotingClient.java】

2: private Channel getAndCreateNameserverChannel() throws InterruptedException {

3: // 返回已选择、可连接Namesrv

4: String addr = this.namesrvAddrChoosed.get();

5: if (addr != null) {

6: ChannelWrapper cw = this.channelTables.get(addr);

7: if (cw != null && cw.isOK()) {

8: return cw.getChannel();

9: }

10: }

11: //

12: final List

  1. Broker 高可用

    启动多个 Broker分组 形成 集群 实现高可用。

    Broker分组 = Master节点x1 + Slave节点xN。

    类似 MySQL,Master节点 提供读写服务,Slave节点 只提供读服务。

3.2 Broker 主从

每个分组,Master节点 不断发送新的 CommitLog 给 Slave节点。 Slave节点 不断上报本地的 CommitLog 已经同步到的位置给 Master节点。

Broker分组 与 Broker分组 之间没有任何关系,不进行通信与数据同步。

消费进度 目前不支持 Master/Slave 同步。

集群内,Master节点 有两种类型:Master_SYNC、Master_ASYNC:前者在 Producer 发送消息时,等待 Slave节点 存储完毕后再返回发送结果,而后者不需要等待。

3.1.1 配置

目前官方提供三套配置:

2m-2s-async

brokerClusterName brokerName brokerRole brokerId

DefaultCluster broker-a ASYNC_MASTER 0

DefaultCluster broker-a SLAVE 1

DefaultCluster broker-b ASYNC_MASTER 0

DefaultCluster broker-b SLAVE 1

2m-2s-sync

brokerClusterName brokerName brokerRole brokerId

DefaultCluster broker-a SYNC_MASTER 0

DefaultCluster broker-a SLAVE 1

DefaultCluster broker-b SYNC_MASTER 0

DefaultCluster broker-b SLAVE 1

2m-noslave

brokerClusterName brokerName brokerRole brokerId

DefaultCluster broker-a ASYNC_MASTER 0

DefaultCluster broker-b ASYNC_MASTER 0

3.1.3 通信协议

Master节点 与 Slave节点 通信协议很简单,只有如下两条。

对象 用途 第几位 字段 数据类型 字节数 说明

Slave=>Master 上报CommitLog已经同步到的物理位置

0 maxPhyOffset Long 8 CommitLog最大物理位置

Master=>Slave 传输新的 CommitLog 数据

0 fromPhyOffset Long 8 CommitLog开始物理位置

1 size Int 4 传输CommitLog数据长度

2 body Bytes size 传输CommitLog数据

转自:http://www.iocoder.cn/RocketMQ/high-availability/

原文地址:https://www.cnblogs.com/jiangjun-x/p/9136532.html

时间: 2024-08-24 10:21:36

RocketMQ 源码分析(三) —— 高可用的相关文章

RocketMQ 源码分析

RocketMQ 源码分析 RocketMQ 的设计思想来自于Kafka,在具体设计时体现了自己的选择和需求,具体差别可以看RocketMQ与Kafka对比(18项差异).接下来记录下自己阅读源码的一些探索. RocketMQ的整体架构如下,可以看到各个组件充当的角色,Name Server 负责维护一些全局的路由信息:当前有哪些broker,每个Topic在哪个broker上等; Broker具体处理消息的存储和服务:生产者和消费者是消息的源头和归宿. 在知道各个角色的基本位置后,就该让程序跑

RocketMQ 源码分析(二) —— Message 存储

CommitLog 结构 CommitLog.MappedFileQueue.MappedFile 的关系如下: CommitLog : MappedFileQueue : MappedFile = 1 : 1 : N. 反应到系统文件如下: ··· Yunai-MacdeMacBook-Pro-2:commitlog yunai$ pwd /Users/yunai/store/commitlog Yunai-MacdeMacBook-Pro-2:commitlog yunai$ ls -l t

Nouveau源码分析(三):NVIDIA设备初始化之nouveau_drm_probe

Nouveau源码分析(三) 向DRM注册了Nouveau驱动之后,内核中的PCI模块就会扫描所有没有对应驱动的设备,然后和nouveau_drm_pci_table对照. 对于匹配的设备,PCI模块就调用对应的probe函数,也就是nouveau_drm_probe. // /drivers/gpu/drm/nouveau/nouveau_drm.c 281 static int nouveau_drm_probe(struct pci_dev *pdev, 282 const struct

[Android]Fragment源码分析(三) 事务

Fragment管理中,不得不谈到的就是它的事务管理,它的事务管理写的非常的出彩.我们先引入一个简单常用的Fragment事务管理代码片段: FragmentTransaction ft = this.getSupportFragmentManager().beginTransaction(); ft.add(R.id.fragmentContainer, fragment, "tag"); ft.addToBackStack("<span style="fo

baksmali和smali源码分析(三)

baksmali 的源码分析 在baksmali进行源码分析之前,需要读者掌握一条主线,因为本身笔者只是由于项目需要用到这套源码,在工作之余的时间里面来进行学习也没有时间和精力熟读源码的每个文件每个方法,但是依据这条主线,至少能够猜出并且猜对baksmali里面的源码的文件大概的作用是什么,这样在修改问题和移植的时候才能做到游刃有余. 这条主线是,baksmali其实只是利用了dexlib2提供的接口,将dex文件读入到一块内存中,这块内存或者说数据结构开辟的大小是跟输入的dex文件相关的,而这

横屏小游戏--萝莉快跑源码分析三

主角出场: 初始化主角 hero = new GameObjHero(); hero->setScale(0.5); hero->setPosition(ccp(100,160)); hero->setVisible(false); addChild(hero,1); 进入GameObjHero类ccp文件 创建主角及动作 this->setContentSize(CCSizeMake(85,90)); //接收触摸事件 CCDirector* pDirector = CCDire

哇!板球 源码分析三

守门员出场 守门员出场,每个守门员是从屏幕的右侧中间的位置随机方向向左侧移动 FielderSprite* fielderSprite1 = FielderSprite::create("pic/fielder.png"); //守门员精灵初始位置为右侧中间位置 fielderSprite1->setPosition(ccp(GOALKEEPER_X, GOALKEEPER_Y)); fielderSprite1->setAnchorPoint(ccp(0.5, 0.5))

RocketMQ源码分析之从官方示例窥探:RocketMQ事务消息实现基本思想

RocketMQ4.3.0版本开始支持事务消息,后续分享将开始将剖析事务消息的实现原理.首先从官方给出的Demo实例入手,以此通往RocketMQ事务消息的世界中. 官方版本未发布之前,从apache rocketmq第一个版本上线后,代码中存在与事务消息相关的代码,例如COMMIT.ROLLBACK.PREPARED,在事务消息未开源之前网上对于事务消息的"声音"基本上是使用类似二阶段提交,主要是根据消息系统标志MessageSysFlag中定义来推测的: TRANSACTION_P

RocketMQ源码分析之RocketMQ事务消息实现原下篇(事务提交或回滚)

本文将重点分析RocketMQ Broker如何处理事务消息提交.回滚命令,根据前面的介绍,其入口EndTransactionProcessor#proce***equest: OperationResult result = new OperationResult();if (MessageSysFlag.TRANSACTION_COMMIT_TYPE == requestHeader.getCommitOrRollback()) { // @1result = this.brokerCont