【Broker简述】
Broker是RocketMQ的核心，大部分“重量级”的工作都是由Broker完成的，包括：
1.接受Producer发过来的消息；
2.处理Consumer的消费信息请求；
3.消息的持久化存储；
4.消息的HA机制；
5.服务端的过滤功能。
【消息存储】
分布式消息队列因为有高可靠性的要求，所以数据要通过磁盘进行持久化存储。
[ 磁盘存储的“快”——顺序写 ]
磁盘存储，使用得当，磁盘的速度完全可以匹配上网络的数据传输速度，目前的高性能磁盘，顺序写速度可以达到600MB/s，超过了一般网卡的传输速度。
[ 磁盘存储的“慢”——随机写 ]
磁盘的随机写的速度只有100KB/s，和顺序写的性能差了好几个数量级。
【消息的存储结构】
RocketMQ的存储是由ConsumeQueue和CommitLog配合完成的。
RocketMQ的存储结构图
CommitLog以物理文件的方式存放，每台Broker上的CommitLog被本机器所有ConsumeQueue共享。
在CommitLog，一个消息的存储长度是不固定的，RocketMQ采用了一些机制，尽量向CommitLog中顺序写，但是随即读。
[ 存储机制这样设计的好处——顺序写，随机读 ]
1.CommitLog顺序写，可以大大提高写入的效率；
2.虽然是随机读，但是利用package机制，可以批量地从磁盘读取，作为cache存到内存中，加速后续的读取速度。
3.为了保证完全的顺序写，需要ConsumeQueue这个中间结构，因为ConsumeQueue里只存储偏移量信息，所以尺寸是有限的。在实际情况中，大部分ConsumeQueue能够被全部读入内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。
[ 如何保证CommitLog和ConsumeQueue的一致性？ ]
CommitLog里存储了Consume Queues、Message Queue、Tag等所有信息，即使ConsumeQueue丢失，也可以通过commitLog完全恢复出来。
[ RocketMQ的Broker机器磁盘上的文件存储结构 ]
【高可用机制】
RocketMQ分布式集群通过Master和Slave机制达到高可用性。
[ 配置中如何区分Master和Slave？ ]
在Broker的配置文件中
Master配置：
brokerId=0 brokerRole=SYNC_MASTER
Slave配置：
brokerId=1 #slave的brokerId>0 brokerRole=SLAVE
Producer只能向Master角色的Broker写消息。
Consumer可以从Master和Slave角色的Broker读消息。
[ 如何提高Producer和Consumer的高可用性？ ]
1.Consumer端的高可用
在Consumer配置文件中，不需要设置是从Master还是Slave读，当Master不可用或者繁忙时，Consumer会被自动切换到从Slave读。
有了自动切换Consumer的机制，当一个Master角色的Broker出现故障，Consumer依然可以从Slave读取消息，不影响Consumer程序。
2.Producer端的高可用性
创建Topic的时候，把Topic的多个MessageQueue创建在多个Broker组上（Broker组：相同的Broker名称，不同的BrokerId组成一个Broker组。），这样当一个Broker组的Master不可用时，其他组的Master依然可用，Producer依然可以发消息。
[ RocketMQ是否支持把Slave自动转成Master？ ]
目前不支持，如果机器资源不足，需要把Slave转成Master，则要手动停止Slave角色的Broker，更改配置文件，用新的配置文件启动Broker。
原文：https://www.cnblogs.com/HigginCui/p/10048559.html