整体架构
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。重试队列和死信队列只有在需要的时候才会被创建出来