整体架构

rocketmq是通过broker主从机制来实现高可用的。相同broker名称，不同brokerid的机器组成一个broker组，brokerId=0表明这个broker是master，brokerId>0表明这个broker是slave。

消息生产的高可用：创建topic时，把topic的多个message queue创建在多个broker组上。这样当一个broker组的master不可用后，producer仍然可以给其他组的master发送消息。 rocketmq目前还不支持主从切换，需要手动切换

消息消费的高可用：consumer并不能配置从master读还是slave读。当master不可用或者繁忙的时候consumer会被自动切换到从slave读。这样当master出现故障后，consumer仍然可以从slave读，保证了消息消费的高可用

消息存储结构

CommitLog：存储消息的元数据

ConsumerQueue：存储消息在CommitLog的索引

IndexFile：提供了一种通过key或者时间区间来查询消息的方法

刷盘机制

在这里插入图片描述

同步刷盘：消息被写入内存的PAGECACHE，返回写成功状态，当内存里的消息量积累到一定程度时，统一触发写磁盘操作，快速写入 。吞吐量高，当磁盘损坏时，会丢失消息异步刷盘：消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，给应用返回消息写成功的状态。吞吐量低，但不会造成消息丢失主从复制

如果一个broker有master和slave时，就需要将master上的消息复制到slave上，复制的方式有两种

同步复制：master和slave均写成功，才返回客户端成功。maste挂了以后可以保证数据不丢失，但是同步复制会增加数据写入延迟，降低吞吐量异步复制：master写成功，返回客户端成功。拥有较低的延迟和较高的吞吐量，但是当master出现故障后，有可能造成数据丢失负载均衡Producer负载均衡

producer在发送消息时，默认轮询所有queue，消息就会被发送到不同的queue上。而queue可以分布在不同的broker上

Consumer负载均衡

默认的分配算法是AllocateMessageQueueAveragely，如下图

还有另外一种平均的算法是AllocateMessageQueueAveragelyByCircle，也是平均分摊每一条queue，只是以环状轮流分queue的形式，如下图：

如果consumer数量比message queue还多，则多会来的consumer会被闲置。所以不要让consumer的数量多于message queue的数量

消息重试和死信队列发送端重试

producer向broker发送消息后，没有收到broker的ack时，rocketmq会自动重试。重试的最大次数和发送超时时间都可以设置。如设置producer3秒内没有发送成功，则重试，重试的最大次数为3

消费端重试顺序消息的重试

对于顺序消息，当Consumer消费消息失败后，RocketMQ会不断进行消息重试，此时后续消息会被阻塞。所以当使用顺序消息的时候，监控一定要做好，避免后续消息被阻塞

无序消息的重试

当消费模式为集群模式时，Broker才会自动进行重试，对于广播消息是不会进行重试的

当consumer消费消息后返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS表明消费消息成功，不会进行重试

当consumer符合如下三种场景之一时，会对消息进行重试

返回ConsumeConcurrentlyStatus.RECONSUME_LATER返回null抛出抛出异常

RocketMQ默认每条消息会被重试16次，超过16次则不再重试，会将消息放到死信队列，

每次重试的时间间隔如下

重试队列和死信队列

当消息消费失败，会被发送到重试队列

当消息消费失败，并达到最大重试次数，rocketmq并不会将消息丢弃，而是将消息发送到死信队列

死信队列有如下特点

里面存的是不能被正常消费的消息有效期与正常消息相同，都是3天，3天后会被删除

重试队列的命名为 %RETRY%消费组名称 死信队列的命名为 %DLQ%消费组名称

一个死信队列包含了一个group id产生的所有消息，不管当前消息处于哪个topic。重试队列和死信队列只有在需要的时候才会被创建出来