RocketMQ学习与分析

RocketMQ学习与分析

• • 1. 架构图
  • 2. 设计
  • • 2.1 设计理念
    • 2.2 设计目标

1. 架构图

在这里插入图片描述

NameServer：

• 类似注册中心，存储了协调治理Broker所需的所有信息（如<borker：Topic路由信息>，HashMap存储）
• NameServer集群各节点之间没有信息同步（producer和consumer轮询所有NameServer节点直到拿到所需信息）
• 通过定期心跳来管理Broker信息，并对外提供接口给producer/consumer访问broker信息。

Broker：

• 消息中枢，持久化消息数据，保存订阅关系、消费进度等。
• Broker的核心在于消息存储：其通过内存映射、顺序写、索引查询保证效率

Topic： topic就是一个消息主题，是一个逻辑概念，实际包含多个属于同一个topic下的消息。在rocketmq中，一个topic会分片到多个broker上，且在每个broker上继续分片成多个Queue，如下图。

在这里插入图片描述

分片到多个broker上是为了突破单点的资源限制（CPU、带宽、内存等），从而实现水平扩展。 分片到多个Queue上是为了负载均衡，rockermq限制了对于N个Queue，只允许<N的Consumer来访问，且这些Consumer会均衡到各个Queue上。

此外，topic对应的消息数据并非真的消息数据，而是指向物理数据的消息索引。

Producer： 生产者，主要用于推送数据，并且有一些默认的定时任务（比如定期获取broker）

Consumer： 消费者，拉模式，定期（!while(this.isStopped(){拉消息}）从broker上拉取可消费信息。拉取时机由Rebalance均衡器进行平衡控制。

2. 设计

2.1 设计理念

• 消息中间件的理想状态是，一条消息能且仅能被消费一次，但要做到这一点，必须牺牲性能。RocketMQ的设计思路是，不去解决这一问题，保证消息至少被消费一次（可能被消费者多次消费），消息消费的幂等由消费者自己实现，这样简化了设计内核，提高了整体性能。
• NameServer极其简单，集群各节点之间互补通信，Topic路由信息无需在集群中保持强一致，只要求最终一致性，且容忍分钟级别的不一致。
• 高效的IO存储，RocketMQ追求消息发送的高吞吐量， RocketMQ将消息存储文件设计成文件组的概念，组内单个文件大小固定，方便引人内存映射机制，所有topic的消息存储基于顺序写，极大地提供了消息写性能，同时为了兼顾消息消费与消息查找，引入了消息消费队列文件与索引文件。

2.2 设计目标

• 顺序消息：保证消息消费者按照消息到达存储服务器的顺序消费
• 消息过滤：消费者只消费自己感兴趣的消息（broker过滤 or 消费者过滤）
• 消息存储：考量维度（消息堆积能力以及消息存储性能）
• 高可用：同步刷盘确保消息不丢失，异步复制（同步双写）避免单点故障
• At-least-once：通过ACK机制确保消息至少被消费一次
• 消息到达低延迟：通过长轮询的机制实现准实时的消息推送
• 消息回溯：消费者想要重新消费已经被消费过的消息
• 消息堆积：削峰的必备能力
• 定时消息：只有到达某个时间点，才能被消费者看到
• 消息重试：消费消息时投递失败，重新投递

参考 消息存储详解 概念模型 rocketmq重点记录 《RocketMQ技术内幕》