写(发送)消息
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都维护了一个主题-消费者下标管理器