后端架构 on 方糖猫Blog

从Redis核心原理到 IPTV 视频项目落地

Tue, 28 Sep 2021 10:00:00 +0800

从Redis核心原理到 IPTV 视频项目落地

先系统梳理 Redis 的核心原理与面试高频知识点，再结合 IPTV（交互式网络电视）视频业务场景，给出可直接运行的 Demo。最后讨论 Redis 为什么不适合长期存储、常见踩坑点，以及 List / Pub/Sub / Stream 三种消息队列实现。

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

Redis（Remote Dictionary Server）是一个开源的、基于内存的高性能键值对数据库，支持多种数据结构、持久化、高可用与分布式扩展。

graph LR
    A[Redis] --> B[内存存储]
    A --> C[数据结构服务器]
    A --> D[单线程命令执行]
    A --> E[IO 多路复用]
    A --> F[持久化 + 高可用]
    B --> G[读写毫秒级]
    C --> H[String/Hash/List/Set/ZSET/Stream/Bitmap/Geo/HyperLogLog]
    F --> I[RDB/AOF/主从/哨兵/Cluster]

与 Memcached 等纯缓存不同，Redis 的核心价值在于丰富的数据结构与原子操作，可以直接在内存中完成排序、计数、限流、去重、队列等复杂逻辑。

二、Redis 为什么快？

面试常问「Redis 为什么快」，通常从四个层面回答：

原因	说明
内存操作	数据存于内存，无需磁盘寻道，访问速度是 SSD 的千倍以上。
单线程命令执行	避免多线程上下文切换、锁竞争，CPU 缓存命中率更高。
IO 多路复用	基于 epoll/kqueue/select 用一个线程处理大量连接。
高效数据结构	String 底层 SDS、ZSET 底层跳表+字典、List 底层 quicklist 等。

graph TB
    subgraph Redis 6/7 线程模型
        M[主线程<br/>命令执行 + IO 多路复用]
        IO[IO 线程池<br/>仅网络读写]
        BG[后台进程<br/>RDB fork / AOF rewrite]
    end
    C1[Client 1] --> M
    C2[Client 2] --> M
    C3[Client 3] --> M
    M <--> IO
    M -.-> BG

注意：Redis 6/7 引入的多线程只用于网络 IO 读写，命令执行依旧是单线程。所以单条慢命令仍会阻塞整个实例。

三、Redis 数据类型与使用场景

3.1 五种基本数据类型

类型	底层结构	典型场景
String	SDS（简单动态字符串）	缓存、计数器、分布式锁、Session
Hash	ziplist / hashtable	对象缓存、用户信息、EPG 节目单
List	quicklist（ziplist + 双向链表）	消息队列、最新 N 条记录
Set	intset / hashtable	去重、共同关注、抽奖
ZSET	ziplist / skiplist + dict	排行榜、延时队列、范围查询

注：表中 ziplist 在 Redis 7 起已被 listpack 替代（动机见 §4.2），配置项改名 *-max-listpack-*，旧名仍兼容。

3.2 三种特殊数据类型

类型	说明	场景
Bitmap	位数组，按位操作	用户签到、在线状态、UV 统计
HyperLogLog	基数估计算法	海量 UV 去重计数，误差约 0.81%
Geo	地理位置坐标	附近的人、POI 搜索

3.3 String：最常用却被低估

String 不仅能存字符串，还能存整数、浮点数、二进制数据。常用命令：

SET key value EX 3600
GET key
INCR view_count
INCRBY view_count 10
SETNX lock:order:123 true EX 30  # 分布式锁核心命令

SDS 的优势（相对 C 字符串）：

O(1) 获取长度。
二进制安全，可存图片、序列化数据。
预分配空间，减少内存重分配次数。
杜绝缓冲区溢出。

3.4 Hash：对象缓存首选

Hash 适合存「一组字段」的对象，比 JSON String 更节省内存、更新更灵活。

HSET user:1001 name "张三" age 30 city "北京"
HGET user:1001 name
HGETALL user:1001
HINCRBY user:1001 age 1

3.5 ZSET：排行榜的王牌

ZSET 底层同时维护「跳表」和「字典」：

跳表（skiplist）：支持 O(log N) 的范围查询和排序。
字典（dict）：支持 O(1) 按 member 查 score。

ZADD hot:tv 1000 "庆余年"
ZADD hot:tv 800 "狂飙"
ZINCRBY hot:tv 50 "狂飙"
ZREVRANGE hot:tv 0 9 WITHSCORES
ZREVRANK hot:tv "狂飙"

3.6 List 与 Stream：队列双雄

List 适合简单队列，Stream 适合生产级消息队列，后面第十四部分会详细对比。

3.7 Bitmap 与 HyperLogLog：海量 UV 统计的利器

Bitmap 为什么能天然去重？

Bitmap 本质是一个超长 bit 数组，每个 bit 只能是 0 或 1。把 user_id 作为偏移量（offset），用户访问一次就把对应位置 1：

天然去重：同一用户重复访问，置的都是同一个 bit，无需额外判断。
极致省内存：1 亿用户只需 1 亿 bit ≈ 12MB；而 Set 存 1 亿个 ID 要占用数 GB。
支持位运算：BITOP AND/OR 可以直接算多日留存（今天访问 AND 昨天也访问）。

SETBIT uv:20210928 10086 1   # 用户 10086 访问
SETBIT uv:20210928 10086 1   # 重复访问，结果不变
BITCOUNT uv:20210928         # 直接得出 UV 数

局限：要求 user_id 是连续整数，ID 稀疏时浪费内存。

HyperLogLog 为什么 12KB 能数一亿？

HyperLogLog 基于概率估计算法：把每个元素 hash 成均匀分布的随机数，观察 hash 值二进制串中前导零的最大个数。

类比抛硬币：想连续抛出 N 次正面，平均要抛 2^N 次。反过来，如果见过最长连续 N 次正面，就估计大约抛了 2^N 次——前导零越多，说明见过的不同元素越多。
单次估计误差大，所以内部用 16384 个分桶（寄存器，每个 6 bit） 分别记录，再取调和平均数消除偶然性，最终误差稳定在 0.81% 左右。
内存恒定 约 12KB，与元素个数无关：统计 1 亿 UV 还是 10 亿 UV 都是 12KB。

PFADD uv:20210928 "user:10086"
PFADD uv:20210928 "user:10086"  # 重复添加不影响计数
PFCOUNT uv:20210928             # 估算 UV

局限：有误差、不可逆（不能取出具体是哪些用户）。

怎么选：

需求	推荐
精确计数、算多日留存（交并集）、ID 是连续整数	Bitmap
只要近似 UV、数据量极大、ID 是任意字符串	HyperLogLog

四、Redis 底层数据结构速览

graph TD
    A[Redis 数据类型] --> B[String]
    A --> C[Hash]
    A --> D[List]
    A --> E[Set]
    A --> F[ZSET]
    B --> G[SDS]
    C --> H[ziplist]
    C --> I[hashtable]
    D --> J[quicklist]
    E --> K[intset]
    E --> L[hashtable]
    F --> M[ziplist]
    F --> N[skiplist + dict]

底层结构	特点
SDS	带长度、预分配、二进制安全。
ziplist	紧凑列表，小数据量时省内存；大数据量时改为 hashtable/skiplist。
listpack	ziplist 的修正版（Redis 7+）：entry 只记自身长度，消灭连锁更新。
quicklist	List 的底层，由多个紧凑块（Redis 7 前是 ziplist，之后是 listpack）节点组成的双向链表。
hashtable	标准哈希表，渐进式 rehash 避免一次性阻塞。
intset	Set 在元素全为整数且数量少时的紧凑实现。
skiplist	多层索引链表，实现 ZSET 的有序范围查询。

下面把 5 种核心结构「画」出来。

4.1 SDS（Simple Dynamic String）

Redis 没有直接用 C 字符串，而是包了 SDS：

flowchart LR
    L["len<br/>已用长度（4B）<br/>= 5"] --- A["alloc<br/>总容量<br/>= 8"] --- F["flags<br/>编码位<br/>= 0"] --- B["buf[]<br/>实际字符/二进制数据<br/>H e l l o \0 ..."]
    N1["O(1) 取长度"] -.-> L
    N2["末尾保留 \0<br/>兼容 C 字符串函数"] -.-> B

len：已用长度，取长度 O(1)。
alloc：分配的总空间；free = alloc - len 可减少内存重分配。
二进制安全：内容中间可以有 \0，长度由 len 决定。
预分配：修改时若 free 足够就不 realloc；不足时按 2 倍或 1MB 上限预分配。

4.2 ziplist（压缩列表）

ziplist 是一块连续内存，把所有 entry 紧凑排列：

flowchart LR
    A["zlbytes<br/>总字节数<br/>4B"] --- B["zltail<br/>尾偏移量<br/>4B"] --- C["zllen<br/>节点数<br/>2B"] --- D["entry1<br/>变长字节"] --- E["entry2<br/>变长字节"] --- F["..."] --- G["zlend<br/>0xFF<br/>1B"]

每个 entry 的内部结构：

flowchart LR
    A["prevlen<br/>前节点长度<br/>1B 或 5B"] --- B["encoding<br/>编码/长度类型<br/>1B 或更多"] --- C["content<br/>实际数据<br/>变长"]

连续内存、无额外指针，所以省内存。
插入/删除需要整体 memmove，因此只用于小数据量。
Hash/List/ZSET 元素少且单元素短时先用 ziplist，超过阈值升级为 hashtable/skiplist。

listpack（Redis 7 的替代者）：ziplist 的致命伤就藏在 prevlen 里——每个 entry 要记录前一个 entry 的长度：前 entry 小于 254 字节时 prevlen 占 1B，达到 254 字节时占 5B。于是一个 entry 从 253 涨到 254 字节，会让后面每个 entry 的 prevlen 从 1B 膨胀到 5B，膨胀又可能触发下一个 entry 继续膨胀——连锁更新，最坏 O(N²)。

listpack 的修法：每个 entry 只记录自己的总长度，且存在 entry 末尾，entry 之间互不引用——改任何一个 entry 都不会波及邻居，连锁更新从根上消失。Redis 7 起 Hash/List/ZSET 的小对象编码全部换成 listpack，配置项同步改名（hash-max-listpack-entries 等，旧的 *-ziplist-* 名仍兼容）。面试回答「ziplist 和 listpack 的区别」，核心就是这一句：ziplist 记前驱长度所以连锁更新，listpack 记自身长度所以免疫。

4.3 quicklist（快速列表）

Redis 3.2 后，List 的底层是 quicklist = 双向链表 + ziplist：

flowchart LR
    H["head"] --> A["ziplist A<br/>[a|b|c]<br/>count=3<br/>sz=..."] <--> B["ziplist B<br/>[d|e|f|g]<br/>count=4<br/>sz=..."] <--> C["..."]
    N["每个节点是一个 ziplist<br/>节点之间用 prev/next 指针连接"] -.-> A

quicklistNode 结构：

flowchart LR
    A["prev<br/>指针"] --- B["next<br/>指针"] --- C["zl<br/>ziplist"] --- D["sz<br/>字节数"] --- E["count<br/>元素个数"] --- F["encoding<br/>是否压缩"]

结合了双向链表「插入删除快」和 ziplist「省内存」的优点。
每个节点只存少量元素，避免单个 ziplist 太大导致 memmove 开销。
Redis 7 起节点从 ziplist 换成 listpack（动机见 §4.2），但 quicklist 的「链表 + 紧凑块」思想不变。

4.4 intset（整数集合）

Set 在元素全为整数且数量少时使用 intset，否则升级为 hashtable：

flowchart LR
    A["encoding<br/>编码类型<br/>2B/4B/8B"] --- B["length<br/>元素个数<br/>4B"] --- C["contents[]<br/>有序整数数组<br/>[1] [3] [5] [7] [9] ..."]

有序数组，支持二分查找 O(log N)。
所有元素用同一 encoding；加入更大范围整数时可能整体升级（如 int16 → int32），升级是 O(N)。
无重复元素（Set 语义）。

4.5 skiplist（跳表）

ZSET 同时维护 skiplist + dict：

skiplist：按 score 排序，支持范围查询 / 排名 O(log N)。
dict：按 member 查 score，O(1)。

普通有序链表只能顺序扫描，跳表加了多层「快速通道」：

flowchart LR
    subgraph L3["level 3"]
        A3["1"] --> B3["9"] --> C3["15"]
    end
    subgraph L2["level 2"]
        A2["1"] --> B2["5"] --> C2["9"] --> D2["13"] --> E2["15"]
    end
    subgraph L1["level 1"]
        A1["1"] --> B1["3"] --> C1["5"] --> D1["7"] --> E1["9"] --> F1["11"] --> G1["13"] --> H1["15"]
    end
    A3 --- A2 --- A1
    B3 --- C2 --- E1
    C3 --- E2 --- H1
    HEAD["头节点"] -.-> A1
    H1 -.-> TAIL["尾节点"]

跳表节点结构：

flowchart LR
    A["member<br/>成员字符串<br/>（sds）"] --- B["score<br/>分数<br/>（double）"] --- C["forward[] 数组<br/>[L1指针， L2指针， L3指针， ...]<br/>最高层数 = 随机 1~32"]

概率平衡：不用像红黑树那样做复杂旋转。
查找 score=11 时，先在高层大步跳跃，再逐层下降，平均 O(log N)。
配合 dict 实现 ZSCORE 的 O(1) 查询。

五、Redis 持久化：RDB 与 AOF

Redis 提供两种持久化方式，各有优劣。

5.1 RDB（Redis Database）

在指定时间间隔内将内存数据集快照写入磁盘。

save 900 1      # 900 秒内至少 1 次修改则触发
save 300 10     # 300 秒内至少 10 次修改则触发
save 60 10000   # 60 秒内至少 10000 次修改则触发

优点：

文件紧凑，适合备份和灾难恢复。
恢复速度快。

缺点：

两次快照之间数据可能丢失。
bgsave 通过 fork() 子进程生成，大数据集时可能阻塞主线程。

5.2 AOF（Append Only File）

将每次写操作命令追加到日志文件。

appendonly yes
appendfsync everysec  # 每秒刷盘一次（推荐）
# appendfsync always  # 每次写都刷盘，最安全但最慢
# appendfsync no      # 由操作系统决定，最快但不安全

优点：

数据安全性更高，默认最多丢失 1 秒数据。

缺点：

文件体积大。
恢复速度慢。
AOF 重写（rewrite）时会占用额外资源。

5.3 混合持久化（Redis 4.0+）

AOF 重写时先写入 RDB 全量数据，再追加增量 AOF，兼顾恢复速度和数据安全。

aof-use-rdb-preamble yes

graph LR
    A[持久化选择] --> B[RDB]
    A --> C[AOF]
    A --> D[混合持久化]
    B --> E[适合备份/快速恢复]
    C --> F[适合低丢失容忍]
    D --> G[生产推荐]

八股重点：Redis 的持久化是「灾难恢复手段」，不是「主存储方案」。

六、过期删除与内存淘汰

6.1 过期删除策略

Redis 对过期 Key 采用两种策略结合：

策略	说明	优点	缺点
惰性删除	访问 Key 时检查是否过期，过期则删除。	CPU 开销小	过期 Key 可能长期占用内存
定期删除	每隔一段时间随机抽查部分 Key 删除。	平衡内存与 CPU	仍可能有漏网之鱼

6.2 内存淘汰策略

当内存达到 maxmemory 时，根据 maxmemory-policy 决定如何淘汰：

策略	说明
`noeviction`	不淘汰，写操作直接报错。
`allkeys-lru`	所有 Key 中淘汰最近最少使用。
`volatile-lru`	只在设置了 TTL 的 Key 中淘汰最近最少使用。
`allkeys-random`	所有 Key 中随机淘汰。
`volatile-random`	只在设置了 TTL 的 Key 中随机淘汰。
`volatile-ttl`	淘汰即将过期的 Key。
`allkeys-lfu`	所有 Key 中淘汰使用频率最低的。
`volatile-lfu`	只在设置了 TTL 的 Key 中淘汰使用频率最低的。

生产建议：

必须设置 maxmemory。
缓存场景推荐 allkeys-lru 或 allkeys-lfu。
有冷热区分时可用 volatile-lru，但必须给 Key 设置 TTL。

七、Redis 高可用架构

7.1 主从复制（Replication）

一主多从，读流量分摊到从节点。

graph LR
    M[Master<br/>写 + 读] -->|全量/增量同步| S1[Slave 1<br/>读]
    M --> S2[Slave 2<br/>读]
    M --> S3[Slave 3<br/>读]

复制过程：

Slave 发送 PSYNC runId offset。
如果 runId 一致且 offset 在复制积压缓冲区中，则增量同步。
否则全量同步：Master 执行 bgsave 生成 RDB，发送给 Slave。

复制延迟问题：

主从异步复制必然存在延迟。
读从库时可能读到旧数据，需要业务容忍或强制走主库。

7.2 哨兵（Sentinel）

实现自动故障转移，解决主节点宕机问题。

graph TB
    subgraph Sentinel 集群
        Se1[Sentinel 1]
        Se2[Sentinel 2]
        Se3[Sentinel 3]
    end
    M[Master] --> S1[Slave 1]
    M --> S2[Slave 2]
    Se1 -->|监控| M
    Se2 -->|监控| M
    Se3 -->|监控| M
    Se1 -.-> Se2
    Se2 -.-> Se3

核心机制：

主观下线（SDOWN）：单个 Sentinel 认为 Master 不可用。
客观下线（ODOWN）：多数 Sentinel 达成一致。
Leader 选举：Sentinel 之间通过 Raft 算法选举出执行故障转移的 Leader。
故障转移：选一个 Slave 提升为 Master，通知其他 Slave 和客户端。

7.3 Cluster 集群

Redis Cluster 采用无中心架构，数据按槽位分布。

graph TB
    subgraph Redis Cluster
        N1[Node 1<br/>0-5460]
        N2[Node 2<br/>5461-10922]
        N3[Node 3<br/>10923-16383]
    end
    N1 <--> N2
    N2 <--> N3
    N1 <--> N3

关键概念：

集群共有 16384 个槽（slot）。
每个 Key 通过 CRC16(key) % 16384 计算所属槽。
每个 Master 负责一部分槽，可配置 Slave 做高可用。
客户端访问错误节点时，会收到 MOVED 或 ASK 重定向。

MOVED vs ASK：

MOVED：槽已经永久迁移到目标节点。
ASK：槽正在迁移中，先访问目标节点一次。

八、事务与 Lua 脚本

8.1 事务（MULTI/EXEC/DISCARD/WATCH）

MULTI
SET a 1
INCR b
EXEC

特点：

命令按顺序入队，EXEC 时一次性执行。
执行期间不会被其他客户端打断。
但没有回滚机制：如果某条命令语法错误，整个事务不执行；如果运行时错误（如 INCR 字符串），后续命令仍会执行。

8.2 Lua 脚本

EVAL "return redis.call('incr', KEYS[1])" 1 counter

特点：

整个脚本作为一个整体在单线程中原子执行。
适用于需要多个命令且要保证原子性的场景，如秒杀、分布式锁、限流。
集群模式下所有 Key 必须落在同一 slot，否则需要加 hash tag，如 {user}:1001:profile。

九、缓存经典问题

9.1 缓存穿透

问题：查询不存在的数据，缓存不命中，请求直接打到数据库。

解法：

缓存空值（设置短 TTL）。
使用布隆过滤器预先判断 Key 是否存在。

9.2 缓存击穿

问题：热点 Key 突然过期，大量请求同时打到数据库。

解法：

热点 Key 设置永不过期，异步更新。
加互斥锁（SETNX），只允许一个线程重建缓存。

9.3 缓存雪崩

问题：大量 Key 同时过期，或 Redis 宕机，数据库压力陡增。

解法：

给 TTL 加随机值，避免同时失效。
多级缓存（本地 + Redis）。
熔断降级。

9.4 缓存与数据库一致性

常见策略：

策略	说明	问题
Cache Aside	读：先读缓存，未命中读 DB 并写回缓存；写：先更新 DB，再删缓存。	短暂不一致
Read/Write Through	由缓存层统一维护 DB 和缓存。	实现复杂
Write Behind	先写缓存，异步写 DB。	可能丢数据

最常用的是 Cache Aside，配合「先更新数据库，再删除缓存」+ 延时双删 + 消息队列补偿，能在大多数场景下保证最终一致。

十、Redis 在 IPTV 系统中的角色

IPTV 系统的特点是：高并发读、强实时性、热点集中、写流量脉冲式。用户在换台、看 EPG、播放点播、抢购付费节目时，系统需要在毫秒级返回结果。

flowchart TB
    subgraph 用户层
        A[机顶盒 / 手机 / Web]
    end

    subgraph 接入层
        B[CDN / 边缘节点]
        C[API Gateway]
    end

    subgraph 应用层
        D[鉴权服务]
        E[EPG 服务]
        F[播放调度服务]
        G[订单 / 秒杀服务]
    end

    subgraph 数据层
        H[(MySQL / 长视频元信息)]
        I[(对象存储 OSS)]
        J[(Redis 缓存 + 实时计算)]
    end

    A --> B --> C
    C --> D & E & F & G
    D --> J
    E --> J
    F --> J
    G --> J
    E --> H
    F --> I
    G --> H
    J -.-> H

场景	Redis 数据结构	作用
用户会话 / Token	String + EXPIRE	毫秒级鉴权
EPG 节目单缓存	Hash / JSON String	减少数据库查询
热播榜单 / 推荐位	Sorted Set (ZSET)	实时排序
播放限速 / 防刷	Lua + INCR + EXPIRE	滑动窗口限流
秒杀 / 付费解锁	SETNX + DECR + Lua	库存扣减
消息通知 / 任务队列	List / Stream	异步解耦

十一、IPTV 项目 Demo

11.1 用户会话缓存

import redis
import uuid
import time

r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

def login(user_id: str, device_id: str, ttl: int = 3600) -> str:
    token = str(uuid.uuid4())
    key = f"session:{token}"
    r.hset(key, mapping={
        "user_id": user_id,
        "device_id": device_id,
        "login_at": str(time.time())
    })
    r.expire(key, ttl)
    return token

def auth(token: str) -> dict | None:
    return r.hgetall(f"session:{token}")

11.2 EPG 节目单缓存

import json
from datetime import datetime

def cache_epg(channel_id: str, programs: list[dict]):
    key = f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}"
    pipe = r.pipeline()
    for p in programs:
        pipe.hset(key, p['start_time'], json.dumps(p))
    pipe.expire(key, 86400 * 2)
    pipe.execute()

def get_program(channel_id: str, start_time: str) -> dict | None:
    data = r.hget(f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}", start_time)
    return json.loads(data) if data else None

11.3 热播排行榜

def record_view(program_id: str, score: float = 1.0):
    r.zincrby("hot:tv:daily", score, program_id)

def top_n(n: int = 10) -> list[tuple[str, float]]:
    return r.zrevrange("hot:tv:daily", 0, n - 1, withscores=True)

11.4 滑动窗口限流

LIMIT_SCRIPT = """
local key = KEYS[1]
local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local min = now - window

redis.call('zremrangebyscore', key, '-inf', min)
local count = redis.call('zcard', key)
if count < limit then
    redis.call('zadd', key, now, now)
    redis.call('expire', key, math.ceil(window / 1000))
    return 1
else
    return 0
end
"""

limiter = r.register_script(LIMIT_SCRIPT)

def allow(user_id: str, max_qps: int = 10, window_ms: int = 1000) -> bool:
    key = f"rate_limit:{user_id}"
    now = int(time.time() * 1000)
    return bool(limiter(keys=[key], args=[window_ms, max_qps, now]))

11.5 秒杀 / 限时解锁

SECKILL_SCRIPT = """
local key = KEYS[1]
local user_id = ARGV[1]
local stock = tonumber(redis.call('get', key) or '0')
if stock <= 0 then
    return -1
end
if redis.call('sismember', key .. ':users', user_id) == 1 then
    return 0
end
redis.call('decr', key)
redis.call('sadd', key .. ':users', user_id)
return 1
"""

seckill = r.register_script(SECKILL_SCRIPT)

def try_buy(activity_id: str, user_id: str, total_stock: int) -> int:
    key = f"seckill:{activity_id}:stock"
    r.setnx(key, total_stock)
    return int(seckill(keys=[key], args=[user_id]))

十二、为什么 Redis 不适合做长期存储？

12.1 持久化不是主存储

RDB 会丢数据，AOF 文件大且恢复慢。Redis 的持久化定位是「灾难恢复」，不是「可靠主存」。

12.2 内存成本过高

内存价格是 SSD 的 10-50 倍。IPTV 的媒资、播放记录、订单流水动辄几十 TB，全放 Redis 不现实。

12.3 单线程执行风险

大数据集下，一个 KEYS *、HGETALL 或慢查询可能阻塞整个实例。

12.4 缺乏复杂查询能力

Redis 不支持 SQL、JOIN、二级索引。长期业务数据需要分析统计时，应使用 MySQL / PostgreSQL / ClickHouse。

结论：

Redis 适合「热数据 + 临时状态 + 实时计算」，价值在于速度；长期存储应交给磁盘数据库 + 对象存储。

十三、Redis 容易踩坑的地方

坑	说明	解法
大 Key	String > 10MB，集合元素百万级	拆分、分片、UNLINK 异步删除
热 Key	单个 Key 被高频访问	本地缓存、Key 分片、Cluster
缓存穿透/击穿/雪崩	缓存失效导致 DB 被打挂	布隆过滤器、互斥锁、随机 TTL
未设置 maxmemory	内存打满后写操作报错	设置 maxmemory 和淘汰策略
误用 KEYS	`KEYS *` 扫描全库阻塞主线程	生产禁用，改用 SCAN
Lua 跨 slot	Cluster 下脚本 Key 不在同一 slot	使用 hash tag `{user}:1001:xxx`
事务没有回滚	EXEC 后某命令失败不会撤销前面命令	业务层保证幂等，或用 Lua
主从延迟	读从库可能读到旧数据	对一致性要求高的读走主库

十四、Redis 做消息队列的方法

14.1 List：轻量队列

flowchart LR
    P[Producer] -->|LPUSH queue:transcode task| R[(Redis List)]
    C[Consumer] -->|BRPOP queue:transcode 5| R
    C --> S[执行转码]

r.lpush("queue:transcode", json.dumps({"video_id": "v123"}))
_, task = r.brpop("queue:transcode", timeout=5)

优点：简单、阻塞读。缺点：无 ACK、无多消费者组、无消息回溯。

14.2 Pub/Sub：实时广播

r.publish("live:start", json.dumps({"channel_id": "cctv1"}))

优点：实时、多订阅者。缺点：不持久化，消费者断线期间消息丢失。

14.3 Stream：生产级队列

r.xadd("mq:events", {"event": "video:play", "user_id": "u10086"})

r.xgroup_create("mq:events", "group_log", id="0", mkstream=True)

messages = r.xreadgroup(
    groupname="group_log",
    consumername="worker_1",
    streams={"mq:events": ">"},
    count=10,
    block=5000
)
for stream, entries in messages:
    for msg_id, fields in entries:
        process(fields)
        r.xack("mq:events", "group_log", msg_id)

优点：支持消费者组、ACK、消息回溯。

方式	推荐场景
List	简单任务队列
Pub/Sub	实时广播
Stream	生产级消息队列

十五、总结

《Redis in Action》的核心思想可以概括为一句话：把 Redis 当成内存里的数据结构工具箱，而不是数据库。

Redis 适合：

缓存加速（会话、配置、热点数据）。
实时计算（排行榜、计数器、限流、秒杀）。
异步解耦（List / Pub/Sub / Stream）。

Redis 不适合：

长期持久化存储。
复杂查询与大数据分析。
超大数据集主存储。

避免踩坑的关键是：控制 Key 大小、设置合理 TTL、配置淘汰策略、慎用阻塞命令、理解持久化边界。Redis 用好了是神兵利器，用错了就是生产事故的导火索。

消息队列总结：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 做异步化改造，欢迎在评论区交流推拉选型、重试策略或高并发调优经验。