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_FLUSH3.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)