写（发送）消息
broker写消息处理器：SendMessageProcessor
rocketmq为每个topic维护M个broker*N（默认值：16）个队列，其写入的并发性扩展性很强大
读（消费）消息
拉取消息处理器（rocketmq消息框架的设计就是采用的：拉模式）：PullMessageProcessor
消费消息下标管理处理器：ConsumerManageProcessor
基于消费下标（按照消费模式配置计算出下次消费的下标）提交消费者下标并存储：org.apache.rocketmq.broker.offset.ConsumerOffsetManager#commitOffset(java.lang.String, java.lang.String, java.lang.String, int, long)
存储模型
写扩散
读扩散
总结
读扩散
优点
- 写入扩展性高
- 存储成本低
缺点
- 订阅者-消息状态维护成本高
- 读取扩展性差
适用场景：重写轻读
写扩散
优点
- 订阅者-消息状态维护成本低
- 读取扩展性高
缺点
- 写入扩展性差
- 存储成本高
使用场景：重读轻写
rocketmq
rocketmq存储模型选型：读扩散。为了弥补消费消息扩展性差的问题，增加了多个broker节点，突破单机性能瓶颈。同样也增加订阅者-消息状态的维护成本（内存、存储、网络成本与broker数量成正比）。为了维护订阅者-消息状态，每个broker都维护了一个主题-消费者下标管理器