【Broker简述】
Broker是RocketMQ的核心，大部分“重量级”的工作都是由Broker完成的，包括：
1.接受Producer发过来的消息；
2.处理Consumer的消费信息请求；
3.消息的持久化存储；
4.消息的HA机制；
5.服务端的过滤功能。
【消息存储】
分布式消息队列因为有高可靠性的要求，所以数据要通过磁盘进行持久化存储。
RocketMQ的消息是存储到磁盘上的，这样既可以保证断电后恢复，也可以不受内存大小的限制。
[ 磁盘存储的“快”——顺序写 ]
磁盘存储，使用得当，磁盘的速度完全可以匹配上网络的数据传输速度，目前的高性能磁盘，顺序写速度可以达到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。
【重点：同步刷盘和异步刷盘】
[ 同步刷盘 ]
[ 异步刷盘 ]
[ 同步刷盘或异步刷盘的配置方式 ]
通过Broker配置文件中的flushDiskType参数设置。
flushDiskType=SYNC_FLUSH #同步刷盘
flushDiskType=ASYNC_FLUSH #异步刷盘
【 重点：同步复制和异步复制 】
如果一个Broker组有Master和Slave，消息需要从Master复制到Slave，有同步复制和异步复制两种方式。
[ 同步、异步复制的优缺点对比 ]
[ 同步异步的配置方式 ]
在Broker的配置文件中的brokerRole参数进行配置：
brokerRole=ASYNC_MASTER #异步复制 brokerRole=SYNC_MASTER #同步复制 brokerRole=SALVE #对于Slave，只有一个参数可选
【小结：推荐的配置方式】
实际业务场景中，要合理设置刷盘方式和主从复制方式。
特别是刷盘方式中的SYNC_FLUSH方式，如果业务频繁地触发写操作，会明显降低性能。
通常情况下，会把Master和Slave的Broker均配置成ASYNC_FLUSH异步刷盘方式。
主从之间配置成SYNC_MASTER同步复制方式。
即：异步刷盘+同步复制