RocketMQ
消息存储结构
RocketMQ 消息的存储是由ConsumeQueue 和CommitLog 配合完成的，
消息真正的物理存储文件是CommitLog, ConsumeQueue 是消息的逻辑队
列，类似数据库的索引文件，存储的是指向物理存储的地址。每个Topic 下
的每个Message Queue 都有一个对应的ConsumeQueue 文件。文件地址在
$ {$storeRoot} \consumequeue$ {topicName} $ { queueld} $ {fileName ｝ 。
流程
1、nameserver启动
nameserver保存如下信息
topic => List
brokername =>BrokerData
clusterName => Set
brokerAddr => brokerLiveInfo
2、broker master注册nameserver
3、broker slave 注册broker master
4、producer 从nameserver找到broker master，进行消息下发
5、broker master进行写操作，建立 group、topic、queue，slave进行同步操作
6、consumer 在nameserver上订阅topic，进行读操作，并返回消费状态
全局顺序
topic的读写队列数设置为1，生产者和消费者的并发设置为1。本质就是放弃了高并发、高吞吐的能力。
部分有序
采用MessageListenerOrderly,编号%队列个数
重复消费
维护消费记录或者是业务上保持幂等性。
解决各种故障对消息的影响
1、多Master 每个Master 带有slave
2、主从设置成sync_master
3、Producer 同步写
4、刷盘策略 sync_flush
如何提升消费速度
1、增加Consumer实例（集群模型下，同一个group），实例数量不可以超过Topic下Read Queue的数量，超出获取不到消息。
2、设置consumerMessageBatchMaxSize（N），在消息多的时候，每次收到的是长度为N的消息链表。
3、丢弃不重要的消息，是consumer尽快追上Producer的进度。
主从同步复制
1、同步属性信息
Broker在启动的时候，判断自己的角色是否是Slave，是的话就启动定时同步任务，获取offset信息
2、同步消息体
Broker slave会通过CommitLog同步，直接进行TCP连接，连接成功后，通过对比Master和Slave的Offeset,不断进行同步