RocketMQ on 方糖猫Blog

多 Worker 分布式渲染：从 HTTP 轮询到 RocketMQ

Fri, 13 Mar 2026 13:00:00 +0800

多 Worker 分布式渲染：从 HTTP 轮询到 RocketMQ

我开发的方糖猫平台的核心链路最后一步是视频渲染。用户提交生成任务后，系统需要把故事板、配音、素材合成为最终的视频文件。这个步骤 CPU/GPU 密集、耗时长、失败率高，单机渲染很快成为瓶颈。这篇文章会复盘我们从 HTTP 轮询架构迁移到 RocketMQ Push 架构的全过程。

一、渲染任务的特性

AI 视频平台的渲染任务有几个典型特征：

特性	影响
耗时长	一个 60 秒视频渲染可能需要 30 秒到 5 分钟
资源密集	CPU/GPU 占用高，单机并发有限
失败率高	素材缺失、字体缺失、内存不足、网络超时都可能失败
不均衡	不同分辨率、不同时长任务耗时差异大
需要重试	失败后最好换一台 Worker 重试，而不是一直卡在原机

这些特性决定了渲染不能放在主服务里同步执行，必须用异步任务队列 + 多 Worker 架构。

二、第一代架构：HTTP 轮询

2.1 设计思路

最早为了快速验证产品，我们用了最简单的方案：

sequenceDiagram
    participant A as API 服务
    participant W as Worker 服务
    A->>W: POST 任务
    A->>W: 查询状态
    W-->>A: 渲染完成

API 服务把渲染任务通过 HTTP POST 发给某个 Worker
Worker 开始渲染，API 服务定时轮询状态
渲染完成后，Worker 回调 API 服务

2.2 代码示例

import requests
import time

class RenderService:
    def submit(self, task_id, render_params):
        worker_url = self.pick_worker()  # 简单轮询选一个
        requests.post(f"{worker_url}/render", json=render_params, timeout=5)

        # 轮询等待完成
        for _ in range(300):
            time.sleep(2)
            status = requests.get(f"{worker_url}/status/{task_id}").json()
            if status["done"]:
                return status["result"]

2.3 问题很快暴露

问题	说明
Worker 负载不均	轮询分配无法感知 Worker 当前负载
单点故障	某个 Worker 挂了，上面的任务就卡住
扩缩容麻烦	新增 Worker 需要改 API 服务配置
失败重试复杂	需要 API 服务记录每个任务发给了哪个 Worker
Windows 开发环境问题	开发环境只有一台机器，无法模拟多 Worker

这个方案支撑了产品早期验证，但当日均任务量超过几百条后，稳定性和扩展性都跟不上了。

三、第二代架构：RocketMQ Push

3.1 为什么选 RocketMQ

我们对比了几种消息队列：

方案	优点	缺点
HTTP 轮询	简单	负载不均、失败处理差
RabbitMQ	功能全面	高可用配置复杂
Kafka	吞吐高	消费端管理重，延迟不如 RocketMQ
RocketMQ	负载均衡好、顺序消息、延迟消息、监控完善	部署稍重

选择 RocketMQ 主要是因为：

原生支持 Push Consumer，自动负载均衡
NameServer 架构适合弹性扩缩容
消息重试、死信队列机制完善
团队对阿里系中间件比较熟悉

3.2 新架构设计

flowchart TD
    A["API 服务"] -- "发送渲染任务" --> T["RocketMQ Topic: video-render"]
    T --> W1["Worker-1"]
    T --> W2["Worker-2"]
    T --> WN["Worker-N"]
    W1 --> D["渲染完成后更新数据库"]
    W2 --> D
    WN --> D
    D --> S["SSE 推送进度给用户"]

关键变化：

API 服务只负责发消息，不关心任务被哪个 Worker 消费
Worker 从 RocketMQ 拉取任务，自动负载均衡
渲染完成后 Worker 更新数据库，并通过 SSE 通知前端
新增 Worker 只需启动新实例，自动加入消费组

3.3 生产者实现

from rocketmq.client import Producer, Message

producer = Producer("render-producer-group")
producer.set_name_server_address("localhost:9876")
producer.start()

def submit_render_task(task_id: str, params: dict):
    body = json.dumps({
        "task_id": task_id,
        "params": params,
        "submitted_at": time.time()
    })
    msg = Message("video-render")
    msg.set_keys(task_id)
    msg.set_tags("normal")
    msg.set_body(body)
    producer.send_sync(msg)

3.4 消费者实现

from rocketmq.client import PushConsumer, ConsumeStatus

class RenderConsumer:
    def __init__(self):
        self.consumer = PushConsumer("render-consumer-group")
        self.consumer.set_name_server_address("localhost:9876")
        self.consumer.subscribe("video-render", "*", self.on_message)

    def on_message(self, msg):
        try:
            data = json.loads(msg.body)
            task_id = data["task_id"]
            params = data["params"]

            # 幂等检查
            if self.is_task_processed(task_id):
                return ConsumeStatus.CONSUME_SUCCESS

            # 更新任务状态为处理中
            self.update_task_status(task_id, "processing")

            # 执行渲染
            result = self.render(params)

            # 更新任务状态为完成
            self.update_task_status(task_id, "completed", result)

            return ConsumeStatus.CONSUME_SUCCESS
        except Exception as e:
            logger.error(f"Render failed: {e}")
            return ConsumeStatus.RECONSUME_LATER

    def start(self):
        self.consumer.start()

四、关键设计细节

4.1 幂等处理

消息队列可能重复投递，渲染任务又是耗时操作，必须做幂等：

def is_task_processed(task_id: str) -> bool:
    """基于数据库状态做幂等判断"""
    task = db.get_task(task_id)
    return task.status in ("completed", "processing")

如果任务已经是 processing 状态，说明可能被其他 Worker 在处理，需要进一步判断心跳时间，避免任务永远卡住。

4.2 心跳与任务认领

每个 Worker 在处理任务时会定时更新心跳：

def update_task_status(task_id, status, result=None):
    db.execute("""
        UPDATE render_task
        SET status = %s,
            result = %s,
            worker_id = %s,
            heartbeat_at = NOW()
        WHERE task_id = %s
    """, (status, result, WORKER_ID, task_id))

如果某个 Worker 挂了，心跳超过阈值的任务会被标记为失败，重新进入队列重试。

4.3 失败重试与死信队列

RocketMQ 支持消费失败自动重试，默认 16 次，间隔递增。如果还是失败，消息进入死信队列：

# 消费失败时返回重试
return ConsumeStatus.RECONSUME_LATER

对于死信消息，我们单独处理：

分析失败原因
通知运营或用户
部分场景自动降级（比如降低分辨率重试）

4.4 并发控制

每个 Worker 同时能处理几个任务，取决于机器配置。我们通过线程池控制：

from concurrent.futures import ThreadPoolExecutor

# 根据 CPU/GPU 核心数设置
executor = ThreadPoolExecutor(max_workers=2)

def on_message(self, msg):
    future = executor.submit(self.handle_render, msg)
    # 注意：PushConsumer 是阻塞回调，这里需要等待结果
    result = future.result()
    return result

实际部署中，我们更推荐一个 Worker 进程只消费一个任务，通过启动多个 Worker 进程来提升并发。

五、Windows 开发环境兼容

5.1 问题

RocketMQ 在 Windows 上部署比较麻烦，开发环境有时候只有一台机器。为了不影响开发效率，我们设计了一个降级策略：

生产环境：RocketMQ Push Consumer
开发环境：HTTP 轮询模拟（单 Worker）

5.2 抽象层设计

class TaskConsumer(ABC):
    @abstractmethod
    def start(self):
        pass

class RocketMQConsumer(TaskConsumer):
    """生产环境使用"""
    pass

class HttpPollConsumer(TaskConsumer):
    """开发环境使用"""
    pass

# 根据配置切换
consumer = RocketMQConsumer() if env == "production" else HttpPollConsumer()

这样业务逻辑完全一致，只是消息消费方式不同。

六、监控与告警

6.1 关键指标

指标	说明
队列堆积量	判断是否需要扩容 Worker
任务平均处理时间	评估渲染性能和资源需求
任务成功率	健康度核心指标
Worker 在线数量	消费组健康状态
重试次数分布	发现系统性问题

6.2 告警规则

队列堆积超过 100 条，持续 5 分钟 → 扩容提醒
任务成功率低于 95% → 人工介入
Worker 数量异常减少 → 服务异常告警

七、演进效果

迁移到 RocketMQ 后，渲染系统的稳定性明显提升：

指标	HTTP 轮询	RocketMQ Push
平均等待时间	X 分钟	Y 分钟
任务成功率	X%	Y%
Worker 利用率	不均	均衡
扩容成本	需要改配置	启动实例即可
失败重试	自建逻辑	原生支持

（待补充真实数据）

八、踩过的坑

8.1 消息体过大

早期的渲染参数里包含完整的素材 URL 列表，消息体很大。RocketMQ 默认单条消息限制 4MB，我们遇到过消息发送失败。

解决：消息体只传 task_id 和关键参数，Worker 消费后自己从数据库/redis 拉取完整参数。

8.2 消费组订阅不一致

不同 Worker 用同一个消费组但订阅了不同 Tag，导致消息分发混乱。

解决：严格规范消费组命名和订阅规则，每个消费组只负责一个 Topic。

8.3 任务卡住没有超时释放

某个 Worker 处理到一半进程挂了，任务状态一直是 processing。

解决：增加心跳检测，心跳超时的任务自动重置为 pending，重新入队。

九、总结

视频渲染是 AI 视频平台里最典型的「重任务」场景，必须用异步队列 + 分布式 Worker 来解决。几个关键经验：

不要过早优化，但也不能过度将就。HTTP 轮询能验证产品，但流量起来后必须升级。
RocketMQ 的 Push Consumer 很适合这种场景，负载均衡和重试机制省去很多自建成本。
幂等和心跳是必须的，否则任务会丢或卡住。
监控要跟上，队列堆积和成功率是最核心的两个指标。

如果你也在做类似的异步任务处理系统，欢迎交流消息队列选型和 Worker 调度经验。

消息队列总结：RabbitMQ、Kafka、RocketMQ 与 Redis MQ 选型对比与实践避坑

Tue, 30 Jun 2020 10:00:00 +0800

消息队列总结：RabbitMQ、Kafka、RocketMQ 与 Redis MQ 选型对比与实践避坑

消息队列是分布式系统里最常见的「异步管道」。这篇笔记把 RabbitMQ、Kafka、RocketMQ 和 Redis MQ 放在一起比较，重点回答：什么时候该用哪个？推和拉到底怎么选？长连接有什么影响？以及实际使用中的避坑和异常处理经验。

一、为什么需要消息队列？

在没有 MQ 的系统中，A 服务调用 B 服务通常是同步的：

A ──同步调用──▶ B ──同步调用──▶ C
     等待返回      等待返回

链路越长，响应越慢，容错越差。MQ 的核心价值是把「同步依赖」变成「异步管道」：

A ──发送消息──▶ MQ ──接收消息──▶ B
   立即返回         异步处理

1.1 MQ 解决的三大问题

解耦：生产方只负责发消息，不用关心谁消费、怎么消费。
异步：把非核心链路（发短信、记日志、发券）从主流程剥离，降低接口 RT。
削峰填谷：突发流量先写入队列，下游按自身能力消费，避免被压垮。

1.2 什么时候必须引入 MQ？

上下游处理速度差异大，同步调用会导致阻塞或超时。
需要保证某些操作最终执行，但不需要实时返回结果。
系统拆分后，多个服务需要感知同一事件。
大促/活动场景下，需要缓冲突发流量。

二、四种 MQ 横向对比

RabbitMQ、Kafka、RocketMQ 是主流企业级 MQ，Redis 也能当轻量 MQ 用，但定位不同。

2.1 核心定位

维度	RocketMQ	RabbitMQ	Kafka	Redis MQ
出身与设计目标	阿里开源，面向在线交易/金融级消息	Erlang 实现，面向通用企业消息	LinkedIn 开源，面向日志采集与流处理	内存数据库，轻量级队列/发布订阅
数据模型	Topic + Queue，支持 Tag 过滤	Exchange + Queue，路由灵活	Topic + Partition，分区有序	List / Stream / PubSub
默认消费方式	Push（长轮询封装）+ Pull	Push（AMQP 推送）	Pull（消费者主动拉取）	Push（PubSub）/ Pull（BLPOP）
顺序消息	分片内有序，Sharding Key 控制	单 Queue 有序	Partition 内有序	单 Stream/列表有序
延迟消息	原生支持 18 个级别	需插件或死信实现	不原生支持，需借助外部组件	无原生支持
事务消息	原生支持	不支持原生事务消息	不支持原生事务消息	不支持
消息持久化	磁盘持久化，支持同步/异步刷盘	磁盘持久化	磁盘持久化，顺序写	默认内存，可持久化但非强项
消息轨迹	原生支持	需额外配置	需额外组件	无

2.2 性能对比

维度	RocketMQ	RabbitMQ	Kafka	Redis MQ
单机吞吐	10 万级 TPS	万级 TPS	百万级 TPS（批量场景）	十万级 TPS（内存操作）
延迟	毫秒级	微秒-毫秒级	毫秒级，批量时更高	微秒-毫秒级
消息堆积能力	强，适合削峰	一般，堆积过多影响性能	极强，专为日志设计	弱，内存容量受限
批量效率	中等	一般	极高	一般

说明：

Kafka 吞吐数字通常来自批量、压缩、顺序写的日志场景；单条小消息低延迟不如 RocketMQ。
RabbitMQ 延迟低，但高吞吐和海量堆积不是强项。
RocketMQ 在「中等吞吐 + 低延迟 + 强堆积」之间取得了较好平衡。
Redis MQ 性能高，但消息堆积、持久化、事务、延迟消息都不完善，适合轻量、临时场景。

2.3 成本与生态

维度	RocketMQ	RabbitMQ	Kafka	Redis MQ
部署复杂度	中等（NameServer + Broker）	低（单节点即可运行）	高（ZooKeeper/KRaft + Broker）	低（Redis 单实例/集群）
运维成本	中等，阿里系文档丰富	低，但 Erlang 问题排查门槛高	高，调优项多	低，Redis 团队普遍熟悉
云服务成熟度	阿里云 RocketMQ 成熟	各云厂商都有托管版	各云厂商 Kafka 托管版成熟	云 Redis 托管版成熟
学习曲线	中等	低	高	低
大数据生态	一般，可与 Flink/Spark 对接	弱	极强，流处理事实标准	弱
语言客户端	Java 最完善，其他语言有社区版	极其丰富	极其丰富	极其丰富

2.4 适用场景推荐

场景	推荐	原因
电商/金融订单、交易消息	RocketMQ	延迟低、事务消息、顺序消息、监控完善
异步任务、分布式 Worker、视频渲染	RocketMQ	PushConsumer 自动负载均衡，失败重试完善
传统企业应用、RPC 解耦、路由复杂	RabbitMQ	简单易用，Exchange 路由灵活，快速上线
日志采集、埋点、实时数仓、流处理	Kafka	吞吐和生态碾压，分区模型适合流计算
事件总线、多语言异构系统	RabbitMQ / Kafka	客户端生态更丰富
需要事务消息且不想自己实现	RocketMQ	原生事务消息是差异化能力
轻量异步通知、缓存队列、临时任务	Redis MQ	部署简单、延迟低，但不要把核心交易交给它
已有 Redis 基础设施，不想引入新组件	Redis MQ	作为过渡方案或辅助队列可用

2.5 一句话选型

可靠交易、事务消息、顺序消息、在线业务  →  RocketMQ
快速搭建、路由灵活、团队规模小          →  RabbitMQ
日志/流处理/大数据管道、吞吐优先          →  Kafka
轻量通知、临时队列、已有 Redis 生态       →  Redis MQ

很多大厂内部是「Kafka 做日志流 + RocketMQ 做业务消息 + RabbitMQ 做轻量任务 + Redis 做缓存/通知」组合使用，不是单选题。

三、底层架构与核心差异

3.1 四种 MQ 架构对比

flowchart LR
    subgraph RocketMQ
        P1[Producer] --> NS[NameServer]
        NS --> B1[Broker Master]
        B1 --> B2[Broker Slave]
        B1 --> C1[Consumer]
    end

    subgraph Kafka
        P2[Producer] --> KZ[ZooKeeper / KRaft]
        KZ --> KB1[Broker 1]
        KZ --> KB2[Broker 2]
        KB1 --> C2[Consumer]
    end

    subgraph RabbitMQ
        P3[Producer] --> EX[Exchange]
        EX --> Q1[Queue A]
        EX --> Q2[Queue B]
        Q1 --> C3[Consumer A]
        Q2 --> C4[Consumer B]
    end

    subgraph RedisMQ
        P4[Producer] --> R[(Redis)]
        R --> C5[Consumer BLPOP]
        R --> C6[Subscriber]
    end

3.2 存储模型

产品	存储结构	核心特点
RocketMQ	CommitLog + ConsumeQueue	所有 Topic 的消息顺序写入同一个 CommitLog，再用 ConsumeQueue 存每个 Queue 的偏移索引。顺序写磁盘，I/O 效率高。
Kafka	Partition Segment + Index	每个 Partition 是独立日志目录，顺序写入 Segment，配合稀疏索引。Partition 间物理隔离。
RabbitMQ	Queue 独立存储	每个 Queue 维护独立索引和存储，Queue 越多元数据开销越大。
Redis MQ	内存 List / Stream	基于内存操作，速度快，但容量受内存限制，持久化可靠性不如专业 MQ。

flowchart TB
    subgraph RocketMQ_Storage["RocketMQ 存储模型"]
        CL[CommitLog<br/>所有消息顺序写]
        CQ1[ConsumeQueue A<br/>偏移索引]
        CQ2[ConsumeQueue B<br/>偏移索引]
        CL --> CQ1
        CL --> CQ2
    end

    subgraph Kafka_Storage["Kafka 存储模型"]
        KP1[TopicA-P0 Log<br/>独立 Partition]
        KP2[TopicA-P1 Log<br/>独立 Partition]
    end

    subgraph RabbitMQ_Storage["RabbitMQ 存储模型"]
        MQ1[Queue A<br/>独立索引]
        MQ2[Queue B<br/>独立索引]
    end

3.3 路由与元数据管理

产品	注册/路由中心	设计哲学
RocketMQ	NameServer	无状态集群，Broker 主动上报路由，Producer/Consumer 定时拉取。最终一致，轻量。
Kafka	ZooKeeper / KRaft	老版本依赖 ZooKeeper 存元数据、选 Controller；新版本用 KRaft 自洽协议。强一致要求更高。
RabbitMQ	内置 Mnesia 数据库	集群节点共享元数据，Erlang 进程模型天然分布式，但集群扩展性相对有限。
Redis MQ	无	依赖 Redis 自身的 Cluster/哨兵做高可用，没有独立路由层。

3.4 复制与高可用

产品	复制方式	特点
RocketMQ	Master-Slave 同步/异步复制	同步复制保证不丢消息，异步复制性能更高。
Kafka	Partition 多副本 + ISR 机制	自动 Failover，成熟度高。
RabbitMQ	普通队列 + 镜像队列	普通队列只存在于一个节点；镜像队列复制到多个节点但吞吐下降。
Redis MQ	主从 + 哨兵 / Cluster	Redis 自身的高可用机制，不是为消息队列专门设计。

四、推、拉模式与长连接

4.1 Push vs Pull 对比

维度	Push（推）	Pull（拉）
控制权	在 Broker	在 Consumer
实时性	高，Broker 有消息就发	依赖拉取间隔，实时性可调
背压能力	较弱，Consumer 处理慢会堆积	强，Consumer 自己控制速率
实现复杂度	低，业务写回调即可	高，需自管 offset、拉取循环
适用场景	实时性要求高、消费轻量	批量处理、消费重、需要控速

4.2 四种 MQ 的推拉实现

产品	消费方式	是否长连接	说明
RocketMQ	长轮询 Pull 封装成 Push	是	Consumer 与 Broker 保持长连接，Broker hold 请求 5 秒左右，有新消息立即返回。
Kafka	消费者主动 Pull	否（可保持连接但非必需）	Consumer 自己决定何时拉、拉多少，灵活性最高。
RabbitMQ	Broker 真 Push（AMQP）	是	Channel 长连接，Broker 把消息塞给 Consumer，处理完 ACK。
Redis MQ	PubSub 推 / BLPOP 拉	是	PubSub 是长连接推送；BLPOP 是阻塞拉取，也算长连接。

4.3 长连接的影响

flowchart LR
    subgraph 长连接优势
        A1[低延迟]
        A2[实时推送]
        A3[减少建连开销]
    end

    subgraph 长连接代价
        B1[连接数消耗大]
        B2[需要心跳保活]
        B3[网络断开感知延迟]
        B4[Consumer 慢会拖垮 Broker]
    end

长连接的好处：

消息到达可以立刻推送给 Consumer，延迟低。
避免频繁建立/断开 TCP 连接的开销。
适合在线业务、实时通知类场景。

长连接的代价：

Broker 需要维护大量连接，连接数成为重要资源。
必须有心跳机制，否则无法及时发现 Consumer 宕机。
Consumer 处理慢时，消息会堆积在 Broker 内存或磁盘，容易把 Broker 压垮。
网络闪断后需要重连、重平衡，可能带来消费抖动。

4.4 选择原则

flowchart TD
    A[选择消费模式] --> B{实时性要求高?}
    B -->|是| C{消费逻辑轻量?}
    B -->|否| D[Pull 模式]
    C -->|是| E[Push 模式]
    C -->|否| F[Pull 模式 或 限流 Push]
    D --> G[批量处理/ETL/数据同步]
    E --> H[在线业务/实时通知]
    F --> I[重任务/视频渲染/大数据]

五、使用注意点与避坑指南

5.1 RocketMQ 避坑

坑	现象	解决
消费组订阅不一致	同一个 ConsumerGroup 订阅不同 Topic/Tag，重平衡混乱	一个 ConsumerGroup 只订阅一个 Topic + 一套 Tag
Tag 用得太细	管理混乱，消费者过滤复杂	Topic 按业务域划分，Tag 做粗粒度过滤
消息体过大	超过 4MB 默认限制，发送失败	消息体只传 ID 和必要字段，完整数据从 DB/OSS 拉取
顺序消息误用	全局顺序严重拖垮吞吐	只在真正需要局部顺序的场景用 Sharding Key
NameServer 路由延迟	Broker 扩缩容后发送到已下线节点	理解最终一致性，扩缩容留足等待时间
自动创建 Topic	生产环境订阅失败或路由错误	提前创建 Topic 和 ConsumerGroup

5.2 Kafka 避坑

坑	现象	解决
Partition 数设置不当	太少并行度不够，太多元数据压力大	根据吞吐和 Consumer 数合理规划
消费者 Rebalance 频繁	消费停滞，组员加入/退出频繁	避免频繁扩缩容，调整 session.timeout.ms
Offset 提交策略不当	重复消费或消息丢失	重要消息手动提交，处理完再 commit
Producer acks=0/1	丢消息	关键业务用 acks=all
单 Partition 热点	某个 Partition 消费滞后	合理设计 Key，避免 Key 倾斜

5.3 RabbitMQ 避坑

坑	现象	解决
镜像队列性能下降	开镜像后吞吐明显降低	只对关键队列开镜像
队列堆积过多	Broker 内存/磁盘告警，性能下降	控制生产速度，及时扩容 Consumer
ACK 模式用错	消息丢失或重复	手动 ACK，处理完再确认
Exchange 路由复杂	消息去向难以追踪	规范命名，做好监控
Connection/Channel 滥用	连接数耗尽	Channel 复用，避免每个消息新建连接

5.4 Redis MQ 避坑

坑	现象	解决
PubSub 消息丢失	Consumer 断线期间的消息收不到	重要消息用 Stream 或专业 MQ
List 做队列无 ACK	Consumer 处理失败消息丢失	用 Stream 的 ACK 机制
内存不足	Redis OOM	设置合理过期时间，控制队列长度
把 Redis 当核心 MQ	数据丢失、无事务、无延迟消息	核心交易链路用 RocketMQ/Kafka

5.5 通用最佳实践

消息体尽量小：传 ID 不传大对象。
幂等设计：所有 Consumer 都要做幂等，MQ 只保证至少一次投递。
监控到位：堆积量、消费 TPS、延迟、死信队列、Broker 资源。
版本一致：服务端和客户端版本不要差距太大。
提前创建资源：生产环境不要依赖自动创建 Topic/Queue。
区分可重试与不可重试异常：网络抖动可以重试，参数错误直接进死信。

六、异常场景处理（分 MQ 说明）

下面列出的异常场景在 RocketMQ、RabbitMQ、Kafka、Redis MQ 中都会遇到，但每种 MQ 提供的机制和最佳实践不同。这一节把四种 MQ 放在一起对比说明。

flowchart LR
    P[Producer 发送层] -->|发送失败/超时| B[Broker 存储层]
    B -->|刷盘/复制失败| C[Consumer 消费层]
    C -->|重复/失败/卡住| Biz[业务异常兜底]

6.1 消息丢失：各 MQ 如何防范

消息丢失通常发生在三个环节：Producer 发送失败、Broker 存储失败、Consumer 消费失败未 ACK。四种 MQ 的防范方式如下：

环节	RocketMQ	RabbitMQ	Kafka	Redis MQ
Producer 发送	同步发送 `SYNC` + 失败重试；避免 `ONEWAY`	使用 `confirm` 模式等待 Broker ACK；开启 Publisher Confirms	设置 `acks=all` + 重试；避免 `acks=0/1`	无发送确认机制，调用成功不代表持久化成功；重要消息不要用 Redis PubSub
Broker 存储	同步刷盘 `SYNC_FLUSH` + 同步复制 `SYNC_MASTER`	队列持久化 + 镜像队列复制；消息标记 `persistent`	`replication.factor >= 3` + `min.insync.replicas` 控制	AOF/ RDB 持久化，但默认异步；主从切换可能丢数据
Consumer 消费	先处理业务再返回 `CONSUME_SUCCESS`	手动 ACK，处理完再 `basic.ack`	处理完再 commit offset	Stream 用 `XACK` 确认；List/ PubSub 无 ACK
兜底	业务对账 + 补偿表	业务对账 + 补偿表	业务对账 + 补偿表	不建议做核心兜底，Redis 本身不是可靠 MQ

关键提醒：

RocketMQ：SYNC_MASTER + SYNC_FLUSH 配置最安全，但性能最低；在线交易通常用 SYNC_MASTER + ASYNC_FLUSH 折中。
RabbitMQ：默认自动 ACK 最容易丢消息，生产环境一定要改手动 ACK。
Kafka：acks=all 配合 min.insync.replicas 才能保证写入 ISR 多数副本；只配置 acks=all 不够。
Redis MQ：Redis 本身不是为消息可靠性设计的，不要把核心交易消息的防丢失交给 Redis。

6.2 消息重复：各 MQ 的投递语义与幂等

四种 MQ 大多只保证「至少一次投递」（at-least-once），重复消费要靠业务层幂等。

MQ	默认投递语义	重复来源	推荐幂等方案
RocketMQ	At-least-once	网络超时重发、Consumer 重启、Broker 重试	消息 `keys` 做唯一业务 Key + 数据库唯一索引
RabbitMQ	At-least-once	连接断开、ACK 未到达 Broker、Consumer 重启	消息 `message_id` 或业务 Key + 幂等表
Kafka	At-least-once	Consumer Rebalance、Offset 提交失败、Producer 重试	业务 Key 去重；Kafka 幂等 Producer 只能去重单会话内重复
Redis MQ	不保证	PubSub 不持久化，断线即丢；Stream 相对可靠但无原生重试	业务侧用 Redis `SETNX` 或数据库唯一索引

# 通用幂等伪代码，适用于四种 MQ
def consume(msg):
    biz_key = extract_biz_key(msg)  # RocketMQ keys / RabbitMQ message_id / Kafka key
    try:
        idempotent_record.insert(biz_key=biz_key, status="processing")
    except UniqueViolation:
        return SUCCESS  # 已处理过，直接成功

    try:
        do_business(msg)
        idempotent_record.update(biz_key, status="done")
        return SUCCESS
    except RetryableException:
        idempotent_record.update(biz_key, status="failed")
        return RETRY
    except NonRetryableException:
        idempotent_record.update(biz_key, status="failed")
        return DEAD_LETTER

6.3 消费失败：重试与死信机制

消费失败后，不同 MQ 的重试和死信（DLQ）机制差异很大：

MQ	重试机制	死信队列	注意事项
RocketMQ	默认最多 16 次，间隔阶梯递增（10s、30s、1m…）	自动进入 `%DLQ%consumer_group`	可区分 `RECONSUME_LATER` 重试和直接成功；重试次数可在 Broker 配置
RabbitMQ	无内置重试，需业务侧或插件实现；常用 TTL + 死信交换器（DLX）做延迟重试	通过 `x-dead-letter-exchange` 配置 DLX/DLQ	手动 ACK 失败或 NACK + requeue=false 进入死信
Kafka	无内置重试次数，失败时 Consumer 自己决定是否重试或跳过	无原生 DLQ，需业务侧或 Kafka Connect 实现	常见做法：失败消息写入专用 Error Topic，由补偿服务处理
Redis MQ	无内置重试	无原生 DLQ	Stream 可配合 Consumer Group 的 Pending List 人工处理；List/ PubSub 无重试能力

flowchart TD
    A[Consumer 处理失败] --> B{MQ 类型}
    B -->|RocketMQ| C[返回 RECONSUME_LATER]
    B -->|RabbitMQ| D[NACK + requeue=false 进 DLX]
    B -->|Kafka| E[写入 Error Topic 或暂停消费]
    B -->|Redis Stream| F[XCLAIM 或人工处理 Pending]
    C --> G{重试超限?}
    G -->|是| H[进入 DLQ]
    G -->|否| C
    D --> H
    E --> I[补偿服务消费 Error Topic]
    F --> J[业务侧补偿]

可重试异常：网络超时、依赖服务短暂不可用、数据库连接池耗尽。

不可重试异常：参数非法、依赖返回 4xx、业务规则冲突、数据不存在。

6.4 业务异常处理

业务异常（如参数错误、状态冲突、规则校验失败）和系统异常（网络、DB、依赖故障）要分开处理。

flowchart TD
    A[Consumer 捕获异常] --> B{异常类型}
    B -->|系统异常<br/>网络/DB/依赖| C[MQ 重试]
    B -->|业务异常<br/>参数/规则/状态冲突| D[记录失败明细]
    D --> E{能否修复?}
    E -->|能| F[人工补偿/修复后重投]
    E -->|不能| G[进死信队列或丢弃]
    C --> H{重试成功?}
    H -->|否| I[进入死信/Error Topic]

MQ	业务异常处理建议
RocketMQ	捕获业务异常后，直接返回 `CONSUME_SUCCESS` 并记录失败原因，避免无意义重试；或主动放入自定义补偿 Topic。
RabbitMQ	业务异常时 `basic.nack(requeue=false)` 直接进死信，不要在 RabbitMQ 里反复重试业务错误。
Kafka	业务异常写入 Error Topic，由补偿服务按业务规则处理；Consumer 继续消费后续消息，避免阻塞 Partition。
Redis MQ	Redis 不适合复杂异常处理；业务异常建议直接记录到数据库或日志，人工介入。

业务异常兜底策略：

记录失败明细：消息内容、异常原因、时间、Consumer 实例、业务 Key。
人工补偿平台：按业务 Key 重投、跳过、标记已处理。
状态机兜底：订单等核心业务要有最终一致性校验。
告警分级：死信队列增长、消费停滞、重试频繁分级告警。
不要无限重试业务异常：参数错误重试 16 次没有意义。

6.5 消息卡住/消费停滞

消费停滞是四种 MQ 都会遇到的异常，但原因和处理方式各有侧重：

MQ	常见原因	处理手段	监控指标
RocketMQ	Consumer 实例少、单条处理慢、Consumer 宕机、下游依赖慢	扩容 Consumer（不超过 Queue 数）、优化消费逻辑、限流、降级	ConsumeProgress 堆积量、消费 TPS
RabbitMQ	队列堆积导致内存/磁盘告警、Consumer 连接断开、Channel 阻塞	扩容 Consumer、控制生产速度、启用队列长度限制	Queue 深度、内存使用率、磁盘告警
Kafka	Partition 消费滞后、Consumer Rebalance 频繁、单 Partition 热点	增加 Partition、优化 Key 设计、调整 `session.timeout.ms`	Consumer Lag、Rebalance 频率
Redis MQ	内存不足、Consumer 断线（PubSub 丢消息）、处理慢	控制队列长度、设置过期时间、用 Stream 替代 PubSub	Redis 内存、Pending List 长度

flowchart LR
    A[消息堆积] --> B{原因}
    B -->|Consumer 少| C[扩容 Consumer]
    B -->|单条处理慢| D[优化消费逻辑/异步化]
    B -->|Consumer 宕机| E[心跳超时触发重平衡]
    B -->|下游依赖慢| F[限流/降级/异步处理]
    B -->|Partition/Queue 热点| G[调整 Key 或增加分区]

6.6 顺序消息异常

顺序消息一旦某条处理卡住，后续消息都会被阻塞，四种 MQ 的处理方式不同：

MQ	顺序模型	异常影响	处理建议
RocketMQ	Sharding Key 路由到同一 MessageQueue，单线程消费	一条失败会阻塞整个 Queue 的后续消息	设置消费超时；失败次数过多时考虑跳过或转移；业务上保证单条处理轻量
RabbitMQ	单 Queue 天然有序，单 Consumer 单线程消费	一个 Consumer 卡住会阻塞整个 Queue	控制单条处理时间；必要时拆分多个 Queue 做局部顺序
Kafka	同一 Partition 内有序，单 Consumer 消费 Partition	一条消息处理慢会阻塞整个 Partition	合理设计 Key，避免单个 Partition 成为热点；业务异常时写入 Error Topic 避免阻塞
Redis MQ	Stream/ List 单节点内有序	单 Consumer 卡住会阻塞后续消费	不建议用 Redis 做强顺序消息；处理异常时直接记录并人工处理

flowchart LR
    A[Queue/Partition 内顺序消费] --> B[消息 1 处理失败或超慢]
    B --> C[消息 2 等待]
    C --> D[消息 3 等待]
    B --> E{如何处理?}
    E -->|跳过| F[破坏顺序性]
    E -->|重试| G[阻塞后续消息]
    E -->|转移| H[进死信/Error Topic]

顺序消息异常处理原则：

只在真正需要顺序的场景使用顺序消息。
单条消息处理要轻量，避免长耗时阻塞队列。
业务上设计「局部顺序」而不是「全局顺序」。
顺序消息失败时，优先考虑业务补偿，而不是无限重试或简单跳过。

七、总结

选型不是单选题：RocketMQ 适合在线业务，Kafka 适合日志/流处理，RabbitMQ 适合轻量快速落地，Redis MQ 适合轻量辅助场景。
推/拉不是对立关系：RocketMQ 的 Push 底层是长轮询 Pull；RabbitMQ 是真 Push；Kafka 是真 Pull。选择看「谁来控制消费节奏」。
长连接是双刃剑：实时性好，但连接维护、背压、心跳都要考虑。
异常处理要分层：发送层确认、Broker 层持久化、消费层幂等 + 重试 + 死信。
业务异常要兜底：区分可重试与不可重试，建立补偿机制和人工介入平台。
避坑靠规范：订阅一致、消息体小、顺序消息慎用、监控到位、版本一致。

参考

RocketMQ 基础科普：推/拉/通知模式、异常处理与高并发实践
《RocketMQ 实战与核心原理》
《RocketMQ 技术内幕》
《Kafka 权威指南》
《RabbitMQ 实战指南》

如果对你有帮助，欢迎在评论区交流你在 MQ 选型或异常处理上的经验。

RocketMQ 基础科普：推/拉/通知模式、异常处理与高并发实践

Sun, 28 Jun 2020 10:00:00 +0800

RocketMQ 基础科普：推/拉/通知模式、异常处理与高并发实践

这篇文章把 RocketMQ 当成一个「分布式异步任务管道」来理解，重点回答六个问题：RocketMQ 和 RabbitMQ、Kafka 怎么选？它们的底层原理差异是什么？消费者到底该推、该拉还是该通知？消息异常了怎么处理？怎么让它扛住高并发？以及那些年我们踩过的坑。

一、RocketMQ 是什么？一句话定位

RocketMQ 是阿里巴巴开源的分布式消息中间件，核心定位是：

高吞吐、低延迟、可堆积、可扩展的异步消息传输与解耦基础设施。

它通常被用来解决三类问题：

解耦：调用方发完消息即可返回，不用等下游处理完。
异步：把非核心链路从同步路径中剥离，比如发券、发短信、记日志。
削峰填谷：突发流量先写入队列，下游按自身能力消费。

RocketMQ 的核心角色很简单：

flowchart TD
    Producer["Producer（消息生产者）"]
    NameServer["NameServer（路由发现）"]
    Broker["Broker（存储与转发消息）"]
    Consumer["Consumer（拉取/接收消息）"]

    Producer -.路由发现.-> NameServer
    Producer --> Broker
    Consumer -.路由发现.-> NameServer
    Broker --> Consumer

Producer：消息生产者，负责把业务消息发到 Broker。
Broker：消息存储和转发节点，分 Master/Slave，负责持久化、投递、重试。
NameServer：轻量级路由注册中心，Producer 和 Consumer 通过它发现 Broker。
Consumer：消息消费者，从 Broker 读取消息并处理。

二、横向对比：RocketMQ / RabbitMQ / Kafka

RocketMQ、RabbitMQ、Kafka 是国内最常见的三种消息中间件。它们都能做异步解耦，但设计哲学差异很大，选型时要结合业务场景、团队能力、运维成本一起看。

2.1 核心定位差异

维度	RocketMQ	RabbitMQ	Kafka
出身与设计目标	阿里开源，面向在线交易/金融级消息	Erlang 实现，面向通用企业消息	LinkedIn 开源，面向日志采集与流处理
数据模型	Topic + Queue，支持 Tag 过滤	Exchange + Queue，路由灵活	Topic + Partition，分区有序
默认消费方式	Push（长轮询封装）+ Pull	Push（AMQP 推送）	Pull（消费者主动拉取）
顺序消息	分片内有序，Sharding Key 控制	单 Queue 有序	Partition 内有序
延迟消息	原生支持 18 个级别	需插件或死信实现	不原生支持，需借助外部组件
事务消息	原生支持	不支持原生事务消息	不支持原生事务消息
消息轨迹	原生支持	需额外配置	需额外组件

2.2 性能对比

维度	RocketMQ	RabbitMQ	Kafka
单机吞吐	10 万级 TPS	万级 TPS	百万级 TPS（批量场景）
延迟	毫秒级	微秒-毫秒级	毫秒级，批量时更高
消息堆积能力	强，适合削峰	一般，堆积过多影响性能	极强，专为日志设计
批量效率	中等	一般	极高

说明：

Kafka 的吞吐数字通常来自批量、压缩、顺序写的日志场景；单条小消息低延迟不如 RocketMQ。
RabbitMQ 延迟低，但高吞吐和海量堆积不是强项。
RocketMQ 在「中等吞吐 + 低延迟 + 强堆积」之间取得了较好平衡。

2.3 成本对比

维度	RocketMQ	RabbitMQ	Kafka
部署复杂度	中等（NameServer + Broker 集群）	低（单节点即可运行）	高（ZooKeeper/KRaft + Broker）
运维成本	中等，阿里系文档丰富	低，但 Erlang 问题排查门槛高	高，调优项多，需要专人维护
云服务成熟度	阿里云 RocketMQ 成熟	各云厂商都有托管版	各云厂商 Kafka 托管版成熟
学习曲线	中等	低	高

2.4 生态对比

维度	RocketMQ	RabbitMQ	Kafka
语言客户端	Java 最完善，其他语言有社区版	极其丰富，几乎所有语言	极其丰富，几乎所有语言
大数据生态	一般，可与 Flink/Spark 对接	弱	极强，流处理事实标准
监控工具	自带控制台 + 阿里云监控	自带 Management UI + Prometheus	Kafka UI + Prometheus + 自建
社区活跃度	国内活跃，Apache 项目	成熟稳定，Pivotal/VMware 背景	极其活跃，Confluent 生态

2.5 适用场景推荐

场景	推荐	原因
电商/金融订单、交易消息	RocketMQ	延迟低、事务消息、顺序消息、监控完善
异步任务、分布式 Worker、视频渲染	RocketMQ	PushConsumer 自动负载均衡，失败重试完善
传统企业应用、RPC 解耦、路由复杂	RabbitMQ	简单易用，Exchange 路由灵活，快速上线
日志采集、埋点、实时数仓、流处理	Kafka	吞吐和生态碾压，分区模型适合流计算
事件总线、多语言异构系统	RabbitMQ / Kafka	客户端生态更丰富
需要事务消息且不想自己实现	RocketMQ	原生事务消息是差异化能力

2.6 一句话选型建议

要可靠交易、事务消息、顺序消息、在线业务 → RocketMQ
要快速搭建、路由灵活、团队规模小 → RabbitMQ
要日志/流处理/大数据管道、吞吐优先 → Kafka

很多大厂内部其实是「Kafka 做日志流 + RocketMQ 做业务消息 + RabbitMQ 做轻量任务」组合使用，而不是单选题。

2.7 底层原理与核心差异

表面的功能差异（延迟消息、事务消息）背后，是三种产品在存储模型、路由发现、复制机制、消费模型上的根本不同。理解这些底层差异，才能真正解释「为什么 Kafka 吞吐高」「为什么 RocketMQ 延迟低」「为什么 RabbitMQ 路由灵活」。

存储模型

产品	存储结构	核心特点
RocketMQ	CommitLog + ConsumeQueue	所有 Topic 的消息顺序写入同一个 CommitLog，再利用 ConsumeQueue 存储每个 Queue 的偏移索引。读消息时先查 ConsumeQueue 拿到物理偏移，再读 CommitLog。
Kafka	Partition Segment + Index	每个 Partition 是一个独立的日志目录，顺序写入 Segment 文件，配合稀疏索引加速消费。Partition 之间物理隔离。
RabbitMQ	Queue 独立存储	每个 Queue 维护独立的消息索引和存储，默认写入 Mnesia/ETS，持久化消息写磁盘。Queue 越多，元数据开销越大。

关键差异：

RocketMQ 的 CommitLog 是全局顺序写，不管有多少 Topic/Queue，磁盘写入都是顺序的，因此单机 I/O 效率很高；读取时需要两次 I/O（ConsumeQueue → CommitLog），但 ConsumeQueue 很小，通常能缓存命中。
Kafka 的 Partition 是物理隔离的，每个 Partition 内部顺序写，但 Partition 多了会形成随机写，所以 Kafka 更适合少量 Topic + 大量 Partition 的日志场景。
RabbitMQ 的 Queue 是逻辑和物理都独立的，每条消息进入 Queue 都要维护索引，高吞吐下容易成为瓶颈。

RocketMQ 存储模型：

flowchart TD
    CL["CommitLog（顺序写）<br/>[msg1][msg2][msg3][msg4][msg5]..."]
    CQ1["ConsumeQueue<br/>TopicA-Q0"]
    CQ2["ConsumeQueue<br/>TopicB-Q0"]

    CL -- "写入后分发偏移索引" --> CQ1
    CL -- "写入后分发偏移索引" --> CQ2

Kafka 存储模型：

flowchart LR
    P0["TopicA-P0 Log<br/>[msg1][msg2]..."]
    P1["TopicA-P1 Log<br/>[msg1][msg2]..."]

路由与元数据管理

产品	注册/路由中心	设计哲学
RocketMQ	NameServer	无状态集群，Broker 主动上报路由信息，Producer/Consumer 定时拉取。最终一致，轻量。
Kafka	ZooKeeper / KRaft	老版本依赖 ZooKeeper 存元数据、选 Controller；新版本用 KRaft 自洽协议。强一致要求更高。
RabbitMQ	内置 Mnesia 数据库	集群节点共享元数据，Erlang 进程模型天然分布式，但集群扩展性相对有限。

关键差异：

NameServer 是「轻量级最终一致」：Broker 启动时向所有 NameServer 注册，Producer 从 NameServer 拿到路由后缓存使用。Broker 宕机后，NameServer 不会主动通知 Producer，而是靠 Producer 心跳/发送失败时刷新路由。这种设计牺牲了一定的实时性，换来了极简的部署和无状态扩展能力。
Kafka 的 Controller 负责元数据一致性：分区副本分配、Leader 选举、ISR 维护都由 Controller 处理，更复杂但也更精确。
RabbitMQ 的元数据在节点间同步：小集群简单，大集群（几百个 Queue）容易出现脑裂和同步压力。

复制与高可用

产品	复制方式	特点
RocketMQ	Master-Slave 同步/异步复制	一个 Master 对应一个或多个 Slave。同步复制保证不丢消息，异步复制性能更高。Slave 可读可切换（需要人工或脚本介入）。
Kafka	Partition 多副本 + ISR 机制	每个 Partition 有 N 个副本，Leader 写，Follower 拉取；只有 ISR 中的副本才能竞选 Leader。自动 Failover，成熟度高。
RabbitMQ	普通队列 + 镜像队列	普通队列只存在于一个节点；镜像队列会把消息复制到多个节点，但吞吐下降明显。

关键差异：

RocketMQ 的复制是 Broker 级别，Master 上所有 Queue 一起复制到 Slave；Kafka 是 Partition 级别，复制粒度更细。
Kafka 的 ISR 是动态维护的，写入延迟受最慢 Follower 影响；RocketMQ 的同步复制是 Master 等待 Slave ACK，延迟相对可控。
RabbitMQ 默认不复制，需要显式配置镜像队列，否则节点宕机就丢队列。

消费模型与 Offset 管理

产品	消费方式	Offset 管理
RocketMQ	长轮询 Pull 封装成 Push	Consumer 本地维护消费进度，定时上报 Broker。支持集群消费和广播消费。
Kafka	消费者主动 Pull	Offset 存在 Kafka 内部 Topic（`__consumer_offsets`），Consumer 提交进度。
RabbitMQ	Broker Push（AMQP）	无 Offset 概念，消息 ACK 后从 Queue 移除。不支持消息回溯。

关键差异：

RocketMQ 的 Push 是「假 Push」：Consumer 向 Broker 发起长轮询请求（默认 5 秒），Broker hold 住连接，有新消息时立即返回，没消息时超时返回再轮询。这样既实现了低延迟，又保留了 Pull 的背压能力。
Kafka 的 Pull 是「真 Pull」：Consumer 自己决定什么时候拉、拉多少，框架不负责推送，灵活性最高。
RabbitMQ 的 Push 是「真 Push」：Broker 把消息塞给 Channel，Consumer 处理完 ACK。如果 Consumer 处理慢，Broker 会堆积在内存或磁盘，容易把 Broker 压垮。

顺序消息的实现

产品	实现方式	限制
RocketMQ	同一 Topic 下，相同 Sharding Key 的消息发送到同一个 Message Queue；Consumer 单线程消费该 Queue	全局顺序需要所有消息进一个 Queue，吞吐极低
Kafka	同一 Partition 内有序；Producer 按 Key 路由到固定 Partition	同 RocketMQ，Partition 内有序，全局有序不可行
RabbitMQ	单 Queue 天然有序；多个 Consumer 竞争消费时会乱序	要顺序消费只能单 Consumer 单线程

三种 MQ 的所谓「顺序消息」本质上都是把需要顺序的消息收敛到同一个最小调度单元（Queue / Partition），然后单线程消费。不存在真正的全局顺序高吞吐方案。

延迟消息的实现

产品	实现方式	特点
RocketMQ	内置 18 个延迟级别，消息先进入 SCHEDULE_TOPIC_XXXX，到期后转回真实 Topic	时间粒度固定，不支持任意时间；实现成熟可靠
Kafka	无原生支持	常用方案：时间轮、RocketMQ 中转、Pulsar 等替代
RabbitMQ	通过 TTL + 死信队列（DLX）实现	每个延迟级别需要一个 Queue，灵活但配置繁琐

事务消息的实现

产品	实现方式	特点
RocketMQ	半消息 + 事务回查	Producer 先发「半消息」（对消费者不可见），本地事务成功后 Commit，失败则 Rollback；Broker 会回查超时事务
Kafka	无原生事务消息	Kafka 有幂等 Producer 和事务 API，但那是「跨分区事务」，不是「本地事务 + 消息发送」的事务消息
RabbitMQ	无原生支持	业务侧自己用本地事务表 + 定时补偿实现

RocketMQ 事务消息的核心流程：

flowchart TD
    A["1. Producer 发送 Half Message 到 Broker"] --> B["2. Producer 执行本地事务（如扣减库存）"]
    B --> C{"本地事务结果"}
    C -->|"成功"| D["Commit"]
    C -->|"失败"| E["Rollback"]
    D --> F["3. Broker 投递消息给消费者"]
    E --> G["3. Broker 删除半消息"]
    C -. "Producer 无响应" .-> H["Broker 主动回查事务状态"]
    H --> C

为什么 RocketMQ 更适合在线业务？

把底层差异串起来看，答案就清晰了：

CommitLog + ConsumeQueue 让它在消息量不大时延迟很低（两次索引查询 + 顺序读），适合在线交易这种「消息体小、QPS 高、延迟敏感」的场景。
NameServer 轻量无状态，部署和扩容简单，不像 Kafka 强依赖 ZooKeeper/KRaft。
原生事务消息和延迟消息，是电商、金融场景的刚需，其他两个 MQ 都需要业务侧自己造轮子。
长轮询 Push 模型对业务开发者友好，自动重平衡、失败重试、死信队列开箱即用。

而 Kafka 更适合海量日志、流计算这种「吞吐优先、延迟可接受、需要分区有序」的场景；RabbitMQ 更适合轻量解耦、路由复杂、快速上线的场景。

三、推、拉、通知三种消费模式：怎么选？

RocketMQ 的消费端主要提供 Push 和 Pull 两种消费方式，实际工程里还经常配合 Notify/回调 一起用。三者不是非此即彼，而是适用场景不同。

3.1 Pull 模式：消费者主动拉取

sequenceDiagram
    participant C as Consumer
    participant B as Broker
    C->>B: 有消息吗？
    B->>C: 有，拿去吧

特点：

消费者按自己的节奏拉消息，控制权在消费端。
可以灵活控制拉取频率、批量大小、并发量。
代码稍复杂，需要自己维护 offset、拉取循环、负载均衡。

适合场景：

消费速度远小于生产速度，需要严格控速。
批量处理、定时任务、数据同步类场景。
对实时性要求不高，或者消费逻辑很重。

权衡：

优点	缺点
控制力强，可背压	实现复杂，易写出空轮询
消费节奏自主	实时性依赖拉取间隔
适合批量/重计算	需要自管 offset 和重平衡

3.2 Push 模式：Broker 主动推送给消费者

RocketMQ 的 PushConsumer 本质上也是 Pull 的长轮询封装，但对业务代码来说更像「Broker 推过来」。

sequenceDiagram
    participant C as Consumer
    participant B as Broker
    C->>B: 注册长轮询
    B->>C: 来消息了，处理一下

特点：

使用简单，业务只写一个回调函数。
RocketMQ 自动处理 offset、重平衡、失败重试。
实时性好，能立刻感知新消息。

适合场景：

大多数在线业务场景，尤其是希望「发完就不用管」的时候。
需要自动负载均衡和失败重试的团队。
消费逻辑相对轻量、可并发扩展。

权衡：

优点	缺点
使用简单，自动重平衡	对消费速度有隐性要求，太慢会堆积
实时性好	默认并发策略可能不适合重任务
失败重试原生支持	需要理解线程模型，否则容易踩坑

3.3 Notify / 回调模式：处理完主动通知上游

消息队列本身不负责回调，但业务常把 MQ 和回调配合起来用：

flowchart LR
    A["上游"] --> MQ["MQ"] --> C["消费者处理"] --> N["回调 / 事件总线 / SSE"] --> U["上游或其他系统"]

特点：

不是 RocketMQ 原生消费模式，而是业务架构模式。
适合「异步任务完成后需要通知调用方」的场景，比如视频渲染、订单状态变更。
通常需要配合幂等、状态机、重试策略一起设计。

适合场景：

任务完成后需要反向通知 UI、APP、第三方系统。
长耗时异步任务 + 进度推送。

3.4 选择原则总结

场景	推荐模式	原因
普通异步解耦、实时性要求一般	PushConsumer	简单、自动、够用
消费很重、需要严格控速/批量	PullConsumer	控制力强，避免被消息压垮
数据同步、ETL、定时批量	Pull / 批量拉取	按批次处理更高效
异步任务完成后要通知调用方	Push + 业务回调/Notify	MQ 解耦 + 回调闭环
不确定怎么选	先 Push，遇到瓶颈再切 Pull	Push 是默认最佳实践

一个常见误区是认为 Push 一定比 Pull 先进。实际上 RocketMQ 的 Push 底层也是拉，只是框架帮你做了。真正决定选型的不是「推或拉」，而是 「谁来控制消费节奏」和「实时性与吞吐的优先级」。

四、异常处理：消息丢了、重复了、卡住了怎么办？

消息队列的异常处理是面试和工程中最核心的部分。RocketMQ 提供了机制，但业务层必须配合。

4.1 消息丢失：从哪里可能丢？

消息丢失通常发生在三个环节：

flowchart LR
    P["Producer"] -- "发送失败" --> B["Broker"] -- "刷盘/同步失败" --> C["Consumer"] -- "消费失败未重试" --> Biz["业务"]

防范措施：

环节	措施	说明
Producer 发送	同步发送 + 失败重试	重要消息用 `send_sync`，不要用 oneway
Broker 存储	同步刷盘 + 主从同步	`SYNC_MASTER` + `SYNC_FLUSH` 保证落盘
Consumer 消费	先处理业务再返回成功	不要先 ACK 再执行业务
极端情况	业务对账/补偿	消息 + 数据库状态机双写，定期对账

RocketMQ 的发送确认策略：

SYNC：同步等待 Broker ACK，最可靠但最慢。
ASYNC：异步发送，失败时回调，吞吐高。
ONEWAY：只发不管，最快但不可靠，适合日志等可丢场景。

4.2 消息重复：不可避免，靠幂等解决

RocketMQ 保证「至少一次投递」，不保证「恰好一次」。网络抖动、Broker 重试、Consumer 重启都会导致重复消费。

幂等设计要点：

唯一业务 Key：发送时给消息设置 keys，消费时用业务 Key 去重。
数据库唯一索引：把业务 Key 作为幂等表的唯一键，重复插入会失败。
状态机防重：如订单状态只能 pending → paid → shipped，重复消息不会触发非法流转。
Redis 去重：短期用 SETNX msg_key 1 配合过期时间，适合无数据库或高速场景。

# 伪代码：基于数据库唯一索引做幂等
def consume(msg):
    biz_key = msg.keys
    try:
        idempotent_record.insert(biz_key=biz_key, status="processing")
    except UniqueViolation:
        return ConsumeStatus.CONSUME_SUCCESS  # 已处理过，直接成功

    try:
        do_business(msg)
        idempotent_record.update(biz_key, status="done")
        return ConsumeStatus.CONSUME_SUCCESS
    except Exception:
        idempotent_record.update(biz_key, status="failed")
        return ConsumeStatus.RECONSUME_LATER

4.3 消费失败：重试与死信队列

RocketMQ 对消费失败的消息会自动重试，默认最多 16 次，间隔逐渐拉长。

重试间隔（默认值，Broker 端可配置）：

第几次	间隔
1	10 秒
2	30 秒
3	1 分钟
…	递增
16	约 2 小时

重试仍然失败后，消息进入 死信队列（DLQ），Topic 名为 %DLQ%consumer_group。

处理建议：

不要无脑重试：如果是参数错误、依赖服务永久不可用，重试再多次也没用，应该直接进死信。
死信要告警+人工介入：DLQ 不是垃圾桶，需要监控和补偿机制。
区分可重试异常和不可重试异常：
- 网络超时 → 可重试
- 参数非法 / 依赖返回 4xx / 业务规则冲突 → 不可重试，直接失败或进死信

def consume(msg):
    try:
        process(msg)
        return ConsumeStatus.CONSUME_SUCCESS
    except RetryableException as e:
        # 可重试异常：网络抖动、依赖短暂不可用
        log.warn(f"retryable: {e}")
        return ConsumeStatus.RECONSUME_LATER
    except NonRetryableException as e:
        # 不可重试异常：直接进死信，避免浪费重试次数
        log.error(f"non-retryable: {e}")
        # 某些客户端可通过返回特定状态或手动移入死信
        return ConsumeStatus.CONSUME_SUCCESS  # 业务侧兜底，记录失败原因

4.4 消息卡住：消费超时与心跳检测

Consumer 处理到一半进程挂了，消息状态可能卡在「处理中」。《RocketMQ 技术内幕》里强调：

消息队列只保证投递，不保证业务逻辑一定完成。

所以业务层需要做：

消费超时控制：给单条消息设置最大处理时间，超时强制释放或重试。
心跳与任务认领：Consumer 处理任务时定时更新心跳，超时时由兜底任务重置状态。
进度监控：关注消费进度（ConsumeProgress），发现停滞及时告警。

# 伪代码：心跳续命 + 超时释放
def process_task(task_id):
    claim_task(task_id, worker_id=WORKER_ID, ttl=300)
    try:
        with heartbeat_renewal(task_id, interval=30):
            do_heavy_work(task_id)
        mark_done(task_id)
    except Exception:
        release_task(task_id)
        raise

五、如何支撑高并发？

RocketMQ 本身的吞吐很高（单机万级 TPS 没问题），但业务侧能不能撑住高并发，取决于怎么用它。

5.1 生产者侧优化

手段	说明
批量发送	把小消息攒成一批发送，减少 RTT
异步发送	关键路径用 `send_async`，失败回调补偿
多 Producer 实例	生产端水平扩展，分摊发送压力
合理选择 Topic/Queue 数量	Queue 数影响并行度，太多会增加元数据开销
关闭不必要的消息轨迹	非核心场景关闭 msg_trace 减少开销

5.2 Broker 侧优化

手段	说明
集群部署	多 Master 多 Slave，避免单点
读写分离（Slave 读）	消费压力大时，从 Slave 拉取减轻 Master 压力
异步刷盘	`ASYNC_FLUSH` 性能更高，但可能丢少量消息
分片存储（CommitLog）	利用顺序写磁盘，提升吞吐
JVM/网卡/磁盘调优	消息队列是 IO 密集型，磁盘 SSD、网卡万兆是基础

5.3 消费者侧优化

手段	说明
增加 Consumer 实例	消费组内实例数 ≤ Queue 数时，扩容能线性提升吞吐
提高单实例并发	PushConsumer 可配置 consumeThreadMin/Max
批量消费	一次拉取多条，合并数据库/Redis 操作
消费逻辑异步化	IO 密集型任务不要阻塞消费线程
本地缓存热点数据	减少重复 RPC/DB 查询

关键公式：

总消费吞吐 = Consumer 实例数 × 每个实例的并发线程数 × 单线程处理 TPS

当 Consumer 实例数达到 Topic 的 Queue 数后，再增加实例也无法提升并行度，这时需要增加 Queue 数或优化单线程处理速度。

5.4 削峰填谷的核心思想

高并发不是无限扩容，而是用队列把流量削平：

flowchart LR
    A["突发流量"] --> B["Broker 队列堆积<br/>（容忍峰值）"] --> C["Consumer 按稳定速率消费<br/>（保护下游）"]

所以设计高并发系统时，Queue 的堆积能力本身就是「容量缓冲」。只要 Consumer 能最终追上来，系统就是健康的。

六、避坑指南

6.1 消费组订阅不一致

坑：同一个 ConsumerGroup 下的不同实例订阅了不同的 Topic 或 Tag，导致重平衡混乱。

解决：一个 ConsumerGroup 只订阅一个 Topic + 一套 Tag 表达式，不要随意变更。

6.2 Tag 用得太细

坑：每个业务场景都建一个 Tag，结果消费者端过滤复杂，Topic 管理混乱。

解决：Topic 按业务域划分，Tag 做粗粒度过滤。不要用一个 Topic 承载完全无关的业务。

6.3 消息体过大

坑：把完整对象、图片二进制、大 JSON 塞进消息体，超过 4MB 默认限制，发送失败。

解决：消息体只传 ID 和必要字段，完整数据由 Consumer 从存储（DB/Redis/OSS）拉取。

6.4 顺序消息误用

坑：为了「简单」把所有消息都当顺序消息发，结果全局顺序严重拖垮吞吐。

解决：RocketMQ 的顺序消息是「分片内有序」，不是全局有序。只在真正需要局部顺序的场景用（比如同一订单的操作按顺序处理），并且用业务 Key 做 Sharding。

6.5 忽视 NameServer 路由更新延迟

坑：Broker 扩缩容后，Producer/Consumer 还没刷新路由，导致发送到已下线的 Broker。

解决：理解 NameServer 是最终一致的路由发现，扩缩容时留足等待时间或主动触发重连。

6.6 Producer/Consumer 启动顺序问题

坑：Consumer 先启动但 Topic 还没创建，订阅失败；或 Producer 先启动但 NameServer 还没 ready。

解决：生产环境用自动化方式提前创建 Topic 和 ConsumerGroup，不要依赖自动创建。

6.7 忽视监控与告警

核心监控指标：

指标	意义
消息堆积量（Consumer Lag）	是否需要扩容 Consumer
消费 TPS	消费能力是否匹配生产
消息生产/消费延迟	端到端延迟是否可接受
死信队列消息数	是否有系统性失败
Broker CPU/内存/磁盘 IO	集群健康度
消费失败重试次数	是否有异常趋势

6.8 版本与客户端兼容性

坑：服务端和客户端版本差距大，出现协议不兼容或特性缺失。

解决：尽量保持服务端与客户端版本一致，升级时先升级服务端再升级客户端，灰度验证。

七、总结

RocketMQ 不是银弹，但在大多数分布式异步场景里是非常稳妥的选择。用好它，关键是理解几个核心原则：

推/拉/通知不是对立关系：Push 适合大多数业务，Pull 适合重任务和批量，Notify 是业务层闭环。
异常处理要分三层：发送层用同步/异步确认，Broker 层用刷盘和主从，消费层用幂等 + 重试 + 死信。
高并发 = 水平扩展 + 削峰填谷：Queue 是缓冲，Consumer 是处理单元，单线程效率决定上限。
避坑的核心是规范：订阅一致、消息体小、顺序消息慎用、监控到位。
选型不是单选题：RocketMQ 适合在线业务，Kafka 适合日志流处理，RabbitMQ 适合轻量快速落地，大厂往往是组合使用。
底层差异决定选型：CommitLog + ConsumeQueue、NameServer、长轮询 Push、原生事务/延迟消息，共同决定了 RocketMQ 在在线业务场景的优势。

参考

《RocketMQ 实战与核心原理》
《RocketMQ 技术内幕》
RocketMQ 消息消费核心原理
RocketMQ 高并发与异常处理实践

如果你也在用 RocketMQ 做异步化改造，欢迎在评论区交流推拉选型、重试策略或高并发调优经验。