rocketmq是什么
- rocketmq是阿里出品，后被apache接手开源，apache rocketmq 因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。
- 简单的pub/sub消息模型
基础模型
扩展模型
- 上图就是一个扩展后的消息模型，包括两个生产者，两个消息Topic，以及两组消费者 Comsumer
- 存储消息Topic的 代理服务器( Broker )，是实际部署过程对应的代理服务器
- 为了消息写入能力的水平扩展，RocketMQ 对 Topic进行了分区，这种操作被称为队列（MessageQueue）
- 为了消费能力的水平扩展，ConsumerGroup的概念应运而生
- 相同的ConsumerGroup下的消费者主要有两种负载均衡模式，即广播模式，和集群模式（图中是最常用的集群模式）
- 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
- 在广播模式下，同一个 ConsumerGroup 中的每个 Consumer 实例都处理全部的队列。需要注意的是，广播模式下因为每个 Consumer 实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。
rocketmq的架构
Producer、Consumer又是如何找到Topic和Broker的地址呢？消息的具体发送和接收又是怎么进行的呢？
rocketmq的部署
rocketmq的基本概念
核心概念
- Producer：消息生产者，通过负载均衡策略将消息发送至 Broker 集群
- Consumer：消息消费者，支持 Push/Pull 模式消费消息，支持集群或广播模式
- Topic：消息的逻辑分类，Producer 按 Topic 发送消息，Consumer 按 Topic 订阅消息
- Queue：Topic 的分区单元，每个 Topic 可划分为多个 Queue 以实现并行处理
- NameServer：轻量级服务发现组件，管理 Broker 路由信息，无状态设计，节点间无通信
- Broker：消息存储与转发节点，支持分布式部署，通过集群保证高可用性
数据流转链路
- Producer 向 NameServer 查询 Broker 地址，发送消息至指定 Topic 的 Queue
- Broker 将消息持久化至 CommitLog（物理存储文件）并生成 ConsumeQueue（逻辑索引）
- Consumer 通过 NameServer 获取 Broker 地址，从 ConsumeQueue 拉取消息偏移量，最终读取 CommitLog 中的实际数据
核心特性
高性能与高可靠
- 单机支持万级队列，堆积亿级消息时仍保持低延迟
- 基于分布式集群和持久化机制（CommitLog + ConsumeQueue）保证消息不丢失
消息类型支持
- 顺序消息：同一队列内严格按生产者发送顺序消费，适用于订单流程等场景
- 事务消息：通过二阶段提交实现消息与本地事务的最终一致性
- 延迟消息：支持 18 个级别的延迟投递（如 1s、5s、10m 等）
- 回溯消息：允许消费者重新消费历史消息（按时间或偏移量）
扩展性
- 通过增加 Queue 数量提升并发处理能力，支持云原生部署（K8s 友好）
存储机制与设计
CommitLog
- 物理存储文件，所有 Topic 的消息按写入顺序追加存储，单个文件默认 1GB
- 随机读取设计，通过消息物理偏移量定位数据位置
ConsumeQueue
- 逻辑队列，存储消息在 CommitLog 中的偏移量、大小和 Tag 哈希值，加速消费查询
- 每个 Topic-Queue 对应独立的 ConsumeQueue 文件
高可用机制
- Broker 主从架构：主节点负责读写，从节点异步复制数据以实现故障切换。 消息重试：支持按次数或时间间隔重投递失败消息
典型应用场景
- 异步解耦：分离核心业务与非关键流程（如订单支付与通知）
- 削峰填谷：应对突发流量，通过消息堆积缓解下游系统压力
- 分布式事务：基于事务消息实现跨系统数据一致性（如库存扣减与订单创建）
- 日志收集：聚合多节点日志，供实时计算或离线分析使用
