措施RocketMQ保证高可用和高性能的几种措施 |可用|保证|

整体架构

本文插图
rocketmq是通过broker主从机制来实现高可用的。相同broker名称，不同brokerid的机器组成一个broker组， brokerId=0表明这个broker是master ， brokerId&gt0表明这个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会不断进行消息重试，此时后续消息会被阻塞。所以当使用顺序消息的时候，监控一定要做好，避免后续消息被阻塞