RocketMQ 笔记1

RocketMQ 物理部署结构


如上图所示, RocketMQ的部署结构有以下特点:


1.Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。
2.Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server。
3.Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。

4.Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。


RocketMQ 数据存储结构


如上图所示,RocketMQ采取了一种数据与索引分离的存储方法。有效降低文件资源、IO资源,内存资源的损耗。即便是阿里这种海量数据,高并发场景也能够有效降低端到端延迟,并具备较强的横向扩展能力。

以上摘自十分钟入门RocketMQ


存储目录结构
{user.dir}/store/
checkpoint
config/consumerOffset.json  topic.json  等保存broker的topic信息,consumer集群消费进度等
index/20180228100504690    索引文件,消息里面设置的key,形成的索引
commitlog/00000000000000000000   消息文件
consumequeue/{topic}/{queueId}/00000000000000000000   consumequeue文件

lock


RocketMQ broker主从配置,conf目录下
org.apache.rocketmq.store.CommitLog.handleHA(AppendMessageResult, PutMessageResult, MessageExt)

1.2m-noslave 多个master没有slave,brokerId为0表示为master

broker-b.properties
brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

2.2m-2s-sync 多主多从,同步双写,写消息时候,master写完后同步写slave,再返回写结果

broker-a.properties
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=SYNC_MASTER
flushDiskType=ASYNC_FLUSH

broker-a-s.properties
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
3.2m-2s-async  多主多从,异步复制,写消息时候,master写完后就返回结果,slave异步复制
brokerRole=ASYNC_MASTER
brokerRole=SLAVE




RocketMQ broker刷盘
SYNC_FLUSH,
ASYNC_FLUSH

org.apache.rocketmq.store.CommitLog.handleDiskFlush(AppendMessageResult, PutMessageResult, MessageExt)

一些理解:
RocketMQ consumequeue 用来把同一topic的消息分在不同的组,写的时候消息可以指定queueId,不指定随机,
在consumer端集群消费时候,按照这个组来分配给同一group的不同consumer,增加读写并发效率,还有负载均衡


consumer消费时候会保存消费进度,具体就是queueId和offset,集群消费需要broker保存这些信息
org.apache.rocketmq.client.consumer.store.OffsetStore

每次拉取消息时候需要发送这两个信息,broker根据这两个信息查询对应消息返回,同时还要返回nextOffset


DefaultMQPushConsumer工作过程


1.RebalanceImpl里面的ConcurrentMap<String/* topic */, Set<MessageQueue>> topicSubscribeInfoTable
保存着topic的所有messageQueue,如何更新的?
org.apache.rocketmq.client.impl.factory.MQClientInstance.start()->startScheduledTask()
->updateTopicRouteInfoFromNameServer()->updateTopicRouteInfoFromNameServer()->
mQClientAPIImpl.getTopicRouteInfoFromNameServer->DefaultMQPushConsumerImpl.updateTopicSubscribeInfo(String, Set<MessageQueue>)
->this.rebalanceImpl.topicSubscribeInfoTable.put(topic, info);






2.负载均衡过程
org.apache.rocketmq.client.impl.factory.MQClientInstance.start()->this.rebalanceService.start()->
每20秒mqClientFactory.doRebalance()->DefaultMQPushConsumerImpl.doRebalance()->
RebalanceImpl.doRebalance(boolean)->rebalanceByTopic->AllocateMessageQueueStrategy.allocate->
updateProcessQueueTableInRebalance->dispatchPullRequest(pullRequestList) 给分配到的messageQueue分配拉取消息请求




3.拉取消息过程
提交pullRequest后->pullMessageService.start()->DefaultMQPushConsumerImpl.pullMessage(PullRequest)->
this.pullAPIWrapper.pullKernelImpl()->PullCallback.onSuccess(PullResult pullResult)->
DefaultMQPushConsumerImpl.this.consumeMessageService.submitConsumeRequest 提交处理消息任务
-> 设置NextOffset再次提交,持续拉取 ->
ConsumeMessageConcurrentlyService.submitConsumeRequest(List<MessageExt>, ProcessQueue, MessageQueue, boolean)
->consumeExecutor.submit(consumeRequest)->ConsumeRequest.run()->

MessageListenerConcurrently.consumeMessage(List<MessageExt>, ConsumeConcurrentlyContext)



阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013038630/article/details/80316033
个人分类: java
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭