RocketMQ 的核心机制

RocketMQ基于“顺序写”“随机读”的原则来设计，利用“零拷贝”技术（nio）

高可用机制

RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的，Master 角色的 Broker 支持读和写，Slave 角色的 Broker 仅支持读，也就是 Producer 只能和 Master 角色的 Broker 连接写人消息；Consumer 可以连接 Master 角色的 Broker，也可以连接 Slave 角色的 Broker 来读取消息。

消费端的高可用性

Master 不可用或者繁忙的时候，Consumer 会被自动切换到从 Slave 读。有了自动切换Consumer这种机制，当一个 Master 角色的机器出现故障后，Consumer 仍然可以从 Slave 读取消息，不影响Consumer 程序。这就达到了消费端的高可用性。

发送端的高可用性

在创建 Topic 的时候，把 Topic 的 MessageQueue 创建在多个 Broker 组上（相同Broker名称，不同brokerId的机器组成一个Broker组），这样当一个 Broker 组的 Master 不可用后，其他组的 Master 仍然可用，Producer 仍然可以发送消息。

同步刷盘和异步刷盘

RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。

异步刷盘：

异步刷盘方式：在返回写成功状态时，消息可能只是被写人了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写人。

同步刷盘：

同步刷盘方式：在返回写成功状态时，消息已经被写人磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。

同步复制和异步复制

异步复制

异步复制方式是只要Master写成功即可反馈给客户端写成功状态。

优缺点

在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写人Slave，有可能会丢失；

同步复制

同步复制方式是等Master和Slave均写成功后才反馈给客户端写成功状态

优缺点

在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写人延迟，降低系统吞吐量。