系统架构 on 方糖猫Blog

从余弦定理到 TikTok：一个用户的推荐流是怎么被算出来的

Thu, 22 Oct 2026 23:10:00 +0800

从余弦定理到 TikTok：一个用户的推荐流是怎么被算出来的

上一篇《千人千面 + 无限瀑布流：推荐 Feed 的完整实现架构》把推荐系统的骨架拆完了：离线、近线、在线三层分工，召回、粗排、精排、重排四层漏斗。但通篇是框图和分工表，读完知道"系统长什么样"，却未必有体感——我的数据，到底是怎么变成我刷到的这一屏的？

这篇换个讲法：造一个用户，给他一晚上的真实行为，跟着他走完全程。线索有三条，正好串起三十年：

吴军 2006 年起在 Google 黑板报连载、2012 年成书的《数学之美》——推荐算法的数学原点；
Netflix 2013 年公开的离线/近线/在线三层实践——工程化的起点（上一篇的主线）；
TikTok 2020 年官方披露的 For You 推荐信号，和字节跳动 2022 年发表的 Monolith 在线训练系统——这套东西被推到的工程极致。

数学的原点：《数学之美》的两章

《数学之美》第 14 章"余弦定理和新闻的分类"讲了一个漂亮的化归：给新闻里每个实词算出 TF-IDF 值，按词汇表位置排成一个向量，一篇新闻就变成了一个特征向量；“新闻分类"这个看似需要理解语义的问题，变成了在向量空间里算余弦相似度的几何问题。第 15 章"矩阵运算和文本处理中的两个分类问题"接着讲：成千上万篇新闻构成的大矩阵，可以用 SVD（奇异值分解）一次拆开，分类在分解后的小矩阵上完成。

推荐系统是同一套数学，换了一张矩阵：把"新闻 × 词汇"换成"用户 × 内容”。余弦相似度回答的问题，从"两篇新闻像不像"变成"这个用户的口味和这条内容像不像"；SVD 分解的那张大矩阵，就是后来协同过滤要分解的用户-物品交互矩阵。

别急着说这是类比——直接手算一遍。假设全站内容只有四个类目：宠物、科技、健身、汽车。用户的口味表示成一个 4 维向量，每个分量是他在该类目上累计的行为强度。

造一个用户：U10086 的一晚

主角 U10086，昨晚刷了一小时短视频，留下这些行为：

时间	行为	内容	类目
22:10	完播	A123「橘猫拆家」	宠物
22:13	点赞	B456「居家哑铃训练」	健身
22:15	1.2 秒划走	C789「新能源车测评」	汽车
22:18	停留 8 秒	D012「AI 编程工具实测」	科技

这些行为不会直接变成画像——中间隔着一层关键设计：内容的类目不是作者上传时选的，是平台算出来的。

内容的标签不是作者标的，是算出来的

一个常见误解：视频的类目来自作者上传时勾选的分区。在 TikTok 这个量级的平台上不是这样。作者自选标签噪声大，还挡不住"标签作弊"——挂个热门标签蹭流量。真实做法是内容理解管道：视频上传后先过一遍机器理解——抽帧做图像分类和目标检测、ASR 把语音转成文字、OCR 读画面上的字、NLP 分析标题和文案——最后由模型产出类目、标签和 embedding 向量。作者的 caption 和 hashtag 只是输入信号之一，没有最终决定权。TikTok 官方披露的三类信号里，“内容信息”（captions、sounds、hashtags）就是这条管道的产物：内容进流量池之前，“这条视频是关于什么的"已由机器定好。

甚至播放之后还在算。前面提到的 item2vec，训练数据就是全站用户的观看行为——被同一批人看完的内容，向量天然相近。也就是说，内容的向量随每一次播放被持续校准，而不是发布那一刻就定格。

用户向量是内容向量的累计

所以系统手里 U10086 的口味画像——宠物 0.55、科技 0.25、健身 0.15、汽车 0.05，即向量 $u = (0.55, 0.25, 0.15, 0.05)$——不是他填的问卷，也不是对人工类目的简单计数，而是他过去几个月每次行为对应的机器内容向量，按行为强度加权累计出来的。两边都是算出来的：内容侧机器识别，用户侧行为聚合。

这个设计值两个好处：

准：作者标错、乱标的类目污染不了画像，用户向量锚定在内容的真实特征上——他看完的是一只真猫，不是一个挂着"萌宠"标签的广告；
细：4 个类目只是教学简化，底下是几百维的 embedding，“橘猫"和"布偶猫"这种类目装不下的区分，向量装得下。

他今晚每一次播放、点赞，都会乘上那条内容的机器向量、计入自己的向量——这正是后面"短期兴趣向量"一节的微观机制。

今晚候选池里有三条内容（向量都出自内容理解管道）：猫视频 $v_1 = (0.9, 0.1, 0, 0)$，哑铃教学 $v_2 = (0.05, 0.1, 0.8, 0.05)$，汽车测评 $v_3 = (0, 0.05, 0, 0.95)$。

余弦相似度的公式就一行：

$$\cos(u, v) = \frac{u \cdot v}{|u||v|}$$

给猫视频算一次：分子是点积 $0.55 \times 0.9 + 0.25 \times 0.1 = 0.52$；分母是两个向量的模长之积 $\sqrt{0.39} \times \sqrt{0.82} \approx 0.565$。结果是 $0.52 / 0.565 \approx 0.92$。三条候选全算完：

候选	余弦相似度
猫视频 $v_1$	0.92
哑铃教学 $v_2$	0.35
汽车测评 $v_3$	0.10

**这就是"推荐"在最原始形态下的全部：一次点积，一次归一化。**今天 TikTok 的排序模型参数量以百亿计，打分函数的内核仍然是这个动作——只是向量从 4 维人工统计变成几百维神经网络学出来的 embedding（item2vec，2016；双塔模型），从"类目"粒度细化到"每条内容"粒度。三十年里数学没有换，换的是向量的生产方式和计算规模。

行为怎么变成画像：Netflix 的三层分工

4 维向量是教学模型，真实系统里的用户向量没法靠人工统计类目得到——内容有几亿条，行为有几十种。工程上的解法就是上一篇展开讲过的 Netflix 三层分工，以及它背后的一整套大数据栈：用户的每一次曝光、点击、停留，客户端上报后先进 Kafka（事件总线）；一份实时流进 Flink 作业，秒级滚动更新短期画像；同时全量落盘到 HDFS（Hadoop 生态的分布式存储），由 Hive（或 Iceberg）建成离线数仓。离线层的 Spark 批任务（天级）从数仓读数据，算物品向量、itemCF 共现矩阵、用户长期兴趣向量；在线层只做查表和轻量推理，画像和榜单都躺在 Redis 里。重活在用户到来之前全部干完。

问题是：一次"完播"和一次"秒划走”，该给短期画像各贡献多少？这个强弱排序不是工程师拍脑袋——TikTok 官方给过答案。

2020 年 6 月 18 日，TikTok 在官方 newsroom 发表 “How TikTok recommends videos #ForYou”，是平台方罕见的一次坦白。它把推荐信号分成三类：

用户交互：点赞、分享、关注、评论、发布的内容、看完的视频；
内容信息：标题文案、声音、话题标签；
设备与账号设置：语言、国家、设备类型——官方明说这类权重更低，因为"用户没有主动把这些表达为偏好”。

更重要的是官方对信号强度的排序：原话是"用户是否把一个较长的视频从头看到尾"这类强兴趣指标，权重远大于"观众和创作者是否在同一国家"这类弱指标。翻译成 U10086 的表格：他完播猫视频这件事的权重，压过他的手机和品牌方在同一城市。

这套强弱排序落到工程上，就是近线层滚动更新的短期兴趣向量——最近 N 次行为对应的物品向量做加权平均：

$$u_{short} = \frac{\sum_{i} w_i \cdot e^{-\Delta t_i / \tau} \cdot v_i}{\sum_{i} w_i \cdot e^{-\Delta t_i / \tau}}$$

权重 $w_i$ 沿行为强度排：完播 3.0、点赞 2.0、停留 5 秒以上 1.5、点击 1.0、秒划走 -0.5（负反馈反向拉）；指数项是时间衰减，越久的行为影响越小。代入 U10086 的一晚：猫视频向量乘 3.0 主导方向，汽车视频乘 -0.5 往反方向拽。他昨晚的每一个动作，在他下次下拉之前，就已经被压缩成这个向量躺在 Redis 里了。

把公式拆开：每个符号是什么

$i$：遍历用户最近 N 次行为的下标。N 常见取 50-200，只保留最近一小段——太久之前的行为对"今晚想看什么"没有预测力；
$v_i$：第 i 次行为涉及的内容向量——就是上一节内容理解管道算出来的那条视频的向量。注意它是物品的向量，不是用户的；用户向量正是由一堆物品向量合成的；
$w_i$：这次行为的强度权重（完播 3.0、点赞 2.0、停留 1.5、点击 1.0、秒划 -0.5），回答"这个动作多能代表他的兴趣"；
$\Delta t_i$：这次行为距今的时间差；
$\tau$：时间衰减常数，控制"多久之前的行为算老"。$\tau$ 取 12 小时，则 12 小时前的行为权重衰减到 $e^{-1} \approx 0.37$，一天前只剩 0.14；
$e^{-\Delta t_i / \tau}$：指数时间衰减因子，越久的行为对当前兴趣越没有发言权；
分母：归一化项。没有它，刷得多的人向量模长就大，“勤奋"会冒充"兴趣浓”；除一下只留方向，不带数量。

一句话：短期兴趣 = 最近看过的内容的向量，按"行为多重 × 时间多近"加权平均。

演算：U10086 的短期向量

把内容向量代入他昨晚的四次行为。$\tau$ 取 0.5 小时，站在 22:30 这一刻计算（D012 的内容向量是 (0.05, 0.85, 0.05, 0.05)，科技向）：

行为	内容向量 $v_i$	强度 $w_i$	距今 $\Delta t_i$	衰减 $e^{-\Delta t_i / \tau}$	有效权重 $w_i \cdot e^{-\Delta t_i / \tau}$
完播猫视频	(0.9, 0.1, 0, 0)	3.0	20 分钟	0.51	1.54
点赞哑铃	(0.05, 0.1, 0.8, 0.05)	2.0	17 分钟	0.57	1.13
秒划汽车	(0, 0.05, 0, 0.95)	-0.5	15 分钟	0.61	-0.30
停留 AI 工具	(0.05, 0.85, 0.05, 0.05)	1.5	12 分钟	0.67	1.01

分子是四个"有效权重 × 内容向量"之和，这里的算术只有两步：标量乘向量、向量相加。全部展开（保留三位小数）：

第一步，标量乘向量——每条内容向量逐分量乘上自己的有效权重：

          有效权重 × 内容向量                =  加权后的向量
猫视频     1.54 × (0.9,  0.1,  0,    0)     = ( 1.386,  0.154,  0,      0)
哑铃       1.13 × (0.05, 0.1,  0.8,  0.05)  = ( 0.057,  0.114,  0.904,  0.057)
汽车      -0.30 × (0,    0.05, 0,    0.95)  = ( 0,     -0.015,  0,     -0.285)
AI工具     1.01 × (0.05, 0.85, 0.05, 0.05)  = ( 0.050,  0.854,  0.050,  0.050)

第二步，逐分量相加——四个向量的同一列相加，每一列就是一个类目方向：

宠物分量： 1.386 + 0.057 + 0      + 0.050 =  1.49
科技分量： 0.154 + 0.114 - 0.015  + 0.854 =  1.11
健身分量： 0     + 0.904 + 0      + 0.050 =  0.96
汽车分量： 0     + 0.057 - 0.285  + 0.050 = -0.18

分子向量就是 (1.49, 1.11, 0.96, -0.18)；分母是有效权重之和 1.54 + 1.13 - 0.30 + 1.01 = 3.38。最后逐分量相除：1.49 / 3.38 ≈ 0.44，1.11 / 3.38 ≈ 0.33，0.96 / 3.38 ≈ 0.28，-0.18 / 3.38 ≈ -0.05。得到：

$$u_{short} \approx (0.44, 0.33, 0.28, -0.05)$$

从第二步的列里能直接读出故事：宠物分量的九成来自那条完播的猫视频（1.49 里它独占 1.386）；汽车这一列，哑铃和 AI 工具带来的两个正贡献（0.057 + 0.050）加起来也抵不过一次秒划的 -0.285——负权重的意义就在这里：他不喜欢的内容在向量里留下的不是零，而是负坐标，检索时会把相似内容往反方向推。

对比他的长期画像 $(0.55, 0.25, 0.15, 0.05)$：一小时的行为已经把科技顶到第二位、健身翻了倍、汽车打成负值。在线服务一般把长短期两个向量融合（拼接或加权和）作为最终用户向量——长期画像管"他是个什么人"，短期向量管"他今晚想看什么"。下一刷召回时，猫和科技内容能同时被捞回来，靠的就是这个融合向量。

TikTok 把闭环推到极致

官方确认的，和官方从没确认的

除了信号分类，TikTok 那篇文章还有一句关键坦白：粉丝数和账号历史爆款都不是直接推荐因素（原话：neither follower count nor previous high-performing videos are direct factors）。这解释了新账号为什么也能出爆款——内容进场不看出身。

中文互联网流传的"流量池"机制要在这里说清边界：新视频先给 200-500 次曝光的小池子，完播率、互动率跑赢同期内容就推进千级、万级的更大池子，逐级叠加放量——这套具体说法出自运营圈的逆向总结，TikTok 和抖音官方从未确认过细节。但它的方向和官方披露自洽：既然粉丝数不算直接因素，新内容就必须有一个"不看出身、先看小范围真实反馈"的冷启动机制，流量池只是这个必然性的具体形态。

flowchart TD
    A["新视频发布<br/>初始小流量池 数百次曝光"] --> B{"完播率 互动率<br/>跑赢同期内容?"}
    B -- "达标" --> C["二级流量池<br/>千级曝光"]
    B -- "不达标" --> D["停止放量<br/>转入自然长尾"]
    C --> E{"数据继续跑赢?"}
    E -- "达标" --> F["更大流量池<br/>万级到百万级"]
    E -- "不达标" --> D

（图为第三方运营经验的通行描述，非官方口径。）

Monolith：连模型本身都在线学习

Netflix 的三层架构里，模型参数是离线训练的，近线只更新特征和画像。字节跳动 2022 年发表的 Monolith（RecSys ‘22，arXiv:2209.07663）把这条边界也打掉了：推荐模型在线训练——行为事件实时变成训练样本回流，模型参数近实时更新。

工程难点在 embedding 表。在线场景下新内容源源不断涌进来，传统哈希表会发生碰撞：两条不同的内容被映射到同一份 embedding，互相污染。Monolith 用 cuckoo hashing 实现无碰撞的 embedding 表，再配合特征过期和低频过滤控制内存，硬是把"在线深度学习"做成了生产级系统。

对比一下闭环速度：Netflix 2013 年的近线层，“行为 → 画像生效"做到秒级已经是当时的极致；Monolith 把"行为 → 模型参数更新"也压到了近实时。闭环速度，就是推荐系统的军备竞赛指标。

跟着 U10086 走一遍四层漏斗

铺垫完了，现在让 U10086 在 23:05 下拉刷新，跟他的数据走完全程。四层漏斗的原理上一篇讲过，这篇只看一件事：每一步的数据长什么样。

召回：1 亿 → 8000

输入：短期兴趣向量 $u_{short}$、最近行为物品列表 [A123, B456, D012]、长期画像。

多路并行，每一路都是查表或检索，没有任何矩阵运算：

召回路	动作	产出
itemCF 协同过滤	Redis 批量查 A123、B456、D012 各自的相似物品 Top50（相似度矩阵是 Spark 离线算好的共现余弦）	约 3000 条，大量猫、健身、科技内容
向量召回	$u_{short}$ 在 Faiss（HNSW 索引）里做近似最近邻检索，几毫秒返回	3000 条
热门榜	直接读 Redis 里 Flink 滚动窗口算好的全站热榜	1000 条
标签/关键词召回	内容元数据（标题、标签、类目）灌在 Elasticsearch 的倒排索引里，拿画像里的高权重标签当查询条件去检索——「搜推一体」里 ES 干的就是这路	约 500 条
新内容池 + 关注产出 + 探索流量	读离线、近线备好的榜单	各几百条

输出：多路合并、去重、按路配额截断——8000 条候选 ID 的列表，每条只带召回来源和粗分。注意一个细节：没有一路会拿 C789（秒划走的汽车视频）当种子去查相似内容，汽车类在召回阶段就已经天然稀疏了。

粗排：8000 → 1000

输入：8000 条候选 + 一批"便宜特征”——从特征存储（Feast 或自研 Feature Store，底层通常是 Redis）批量读出物品热度分、质量分、该用户的类目偏好分、历史 CTR。

计算：轻量模型打分（简化双塔就是一次向量点积，GBDT 就是几千次小树遍历——XGBoost / LightGBM），单条成本压到微秒级。

输出：每条一个粗排分，截断 Top 1000：

cat_video_8891   (A123 的相似内容)   0.81   ← 和短期向量点积极高
ai_tool_3302     (D012 的相似内容)   0.74
hot_funny_1102   (热门榜兜底)        0.62
car_review_5567                      0.05   ← 秒划负反馈直接压死

精排：1000 → 200

输入：1000 条候选 + 全量特征拼接——用户画像（Redis KV 读出）、物品特征、近线实时特征（最近一小时的点击序列，Flink 产出）、实时上下文（23:05、手机、WiFi）。

计算：深度排序模型（DIN 系，阿里 2018 年 KDD 发表）在推理服务（TF Serving 或 NVIDIA Triton，GPU 批量矩阵乘）上跑推理。DIN 的注意力机制值得演算一步：给候选 cat_video_8891 打分时，模型给 U10086 的历史行为分配权重——同为猫视频的 A123 权重拉到最高，B456 次之，C789 趋近于零，输出高 pCTR；而给 car_review_5567 打分时，被注意机制激活的恰恰是 C789——方向是负的。同一个用户的历史，在不同候选面前讲出不同的故事，这是 DIN 相比"死板的平均历史向量"的本质进步。

输出：每条候选一对预测值 (pCTR, 预估观看时长），加权成综合分后排序，截断 Top 200。

重排：200 → 20

输入：200 条带精排分的列表。这一层几乎不算模型，全是规则：

已曝光过滤：查 Redis 里 user:10086:seen 集合（或布隆过滤器），剔除本次 session 已刷过的 15 条；
负反馈硬屏蔽：汽车类目整体降权——秒划走加历史"不感兴趣"记录；
多样性打散：同作者最多 2 条、相邻 3 条不同类目——Top 200 里连着的 8 条猫视频被打散重插；
混排：第 4 位插入广告（广告单独按 eCPM = 出价 × 预估点击率排序选出），第 9 位插一条关注博主的更新；
业务护栏：过滤审核中内容，新内容扶持配额 5%——这就是流量池机制落在自然流量里的那一小块。

输出：

{
  "items": ["...20 条：16 条自然内容 + 2 条广告 + 1 条关注更新 + 1 条新内容扶持..."],
  "next_cursor": "eyJscCI6MC44MSwiYmF0Y2giOiJUYjI5..."
}

游标里封着最后一条的排序分、本次批次号、过期时间，客户端不许解析。同时这 20 条写入已曝光集合，曝光和后续行为事件经 Kafka 回流——闭环合上，U10086 的下一刷已经在被这一刷改写。

沿途的三方件总表

位置	工具	角色
事件总线	Kafka	行为事件解耦、削峰、可回放
数据底座	Hadoop（HDFS）+ Hive / Iceberg	全量行为日志落盘，离线数仓
离线计算	Spark	模型训练、itemCF 共现矩阵、物品向量
近线计算	Flink	秒级更新短期画像、滚动热榜
在线训练	Monolith（字节自研，论文开源）	模型参数近实时更新
在线 KV	Redis（或 HBase）	画像、榜单、已曝光集合、itemCF 结果
向量检索	Faiss / HNSWlib / Milvus	双塔向量的近似最近邻召回
倒排索引	Elasticsearch	标签/关键词召回路，「搜推一体」的内容检索
特征平台	Feast 或自研 Feature Store	离线、在线特征一致性
模型推理	TF Serving / NVIDIA Triton	精排批量打分
轻量模型	XGBoost / LightGBM	粗排
辅助	布隆过滤器、规则引擎	已曝光去重、重排策略

这套链路怎么扛住高并发

漏斗走完了，但还有一个工程问题没回答：几十毫秒的延迟预算，乘以几十万的并发请求，靠什么扛？先把账算出来。假设 1 亿日活、人均 50 次下拉：平均约 6 万次请求/秒，晚高峰按 3-5 倍算是 20-30 万 QPS。每次下拉背后是几十上百次 KV 读取、一次向量检索、一次千级候选的模型推理。能扛住靠的不是某台快机器，是一组选型决策：

Redis：O(1) 查表 + 批量读。 单实例简单 GET 是十万级 QPS、亚毫秒延迟；一次召回要查几十上百个 key（itemCF 种子物品、画像、热榜），用 mget 合并成一次网络往返，QPS 压力直接降一个量级；集群模式水平分片，容量不够就加分片。已曝光集合的布隆过滤器也放在这里。

向量检索：这是召回里唯一真正"算"的地方，也是选型的重点。 几个主流方案的性能画像（百万到十亿级向量、TopK 检索）：

方案	形态	性能画像	适用场景
Faiss（Meta）	嵌入服务进程内的库	没有网络和序列化开销；IVF+PQ 量化后单机可扛亿级向量，检索毫秒级	召回服务内嵌，延迟敏感场景的主力
HNSWlib	嵌入库	图索引召回率高（95% 以上），代价是全量向量驻内存，内存开销大	中等规模、高精度
ScaNN（Google）	嵌入库	各向异性量化，同等召回率下 QPS 领先	内嵌、高 QPS
Milvus	独立分布式服务	存算分离、支持 GPU 索引，十亿级横向扩展	多业务共享的向量中台
Elasticsearch kNN	搜索引擎插件	复用现有 ES 集群，开箱即用，但 QPS 和召回率都不及专用索引	小规模、搜推一体

工程上的关键判断：召回的向量检索优先用内嵌库（Faiss / HNSWlib），省掉一次 RPC——30 万 QPS 面前，每次网络往返都是命。Milvus 这类独立服务的价值在多团队共享、在线扩缩容和统一的向量管理，不在单点延迟。内容池上到十亿级，靠 PQ 量化把每条向量从几百字节浮点压成几十字节编码，再加分片。

Kafka：百万级消息/秒是常态负载。 曝光点击的洪峰对它来说不算事；真正要设计的是分区数（决定下游消费者的并行上限）和消费滞后监控——滞后就是"画像生效延迟"，直接等于用户体感。

Flink：状态在本地的流计算。 短期画像的滚动更新是 keyed state，状态读写走本地 RocksDB，不回远程存储——这是近线层敢吞全量事件流的原因。反过来说，一旦作业挂掉从 checkpoint 恢复，RocksDB 状态的加载时间就是画像的"失明时间"，所以 checkpoint 间隔要按业务能容忍的失明时长来定。

GPU 推理：批量摊薄。 精排把 1000 条候选拼成一个大 batch 一次过 GPU，摊到每条只有几微秒；Triton 的动态批处理（dynamic batching）会在毫秒级窗口里把多个请求的 batch 攒起来再推理，用一点点延迟换几倍吞吐——这是"几十毫秒预算"能成立的关键手法之一。

共同的模式只有一条：所有重活提前算完存起来，在线路径上只剩内存级查询和批量推理——30 万 QPS 里，没有一个请求需要"现场思考"。

收尾：数学没变，闭环变快

走完全程回头看，三十年里真正变化的不是数学：

2006 年，吴军讲余弦定理给新闻分类——打分内核从那时起就是向量点积，今天依然如此；
2013 年，Netflix 定下三层分工——把计算摊到用户到来之前，至今是主流形态；
2020 年，TikTok 官方坦白完播是强信号、粉丝数不是直接因素——行为强度加权第一次有了平台方背书；
2022 年，Monolith 把模型训练本身搬进在线链路——闭环的最后一段延迟也被压缩。

推荐系统真正的军备竞赛，从来不是"谁的公式更巧妙"，而是谁的闭环转得更快：从用户划走一条汽车视频，到系统少推汽车内容，中间隔了几秒还是几天。U10086 今晚的每一次停留和划走都在投票，明早打开 App 时看到的那个"更懂他"的首页，没有一次是当场算出来的——全是昨晚就已开始的计算，刚好在他到来之前完成。

相关阅读：《千人千面 + 无限瀑布流：推荐 Feed 的完整实现架构》——本文的架构视角姊妹篇，讲四层漏斗的原理和无限下拉的分页协议。

参考：吴军《数学之美》（第三版，人民邮电出版社）第 14、15 章；TikTok Newsroom, “How TikTok recommends videos #ForYou”, 2020-06-18（newsroom.tiktok.com/en-us/how-tiktok-recommends-videos-for-you）；Liu et al., “Monolith: Real Time Recommendation System With Collisionless Embedding Table”, RecSys 2022, arXiv:2209.07663；“流量池"分级机制为运营圈第三方经验总结，非官方披露口径。

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

Mon, 19 Oct 2026 10:00:00 +0800

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

过去几年我一直在做一个面向海外的 C 端 IPTV 产品（STB 机顶盒 + 移动端，多品牌多租户，跑在 AWS 上）。这篇文章是我对这套系统架构的复盘：高并发、高可用、高性能、高安全、缓存一致性这几件事我们分别是怎么做的、踩过什么坑。过程中我们落地了不少 Netflix 的开源组件和公开实践（Hystrix、EVCache、Zuul 的网关思想、混沌工程等），但每一个决策都是经过我们自己生产环境验证或修正的，不是照搬。文中方案细节来自真实的系统设计文档（Video Cloud 目标模型、vod-auth、CloudRouter、DRM、网盘整改等），脱敏后分享。

一、先搞清楚对手：C 端 IPTV 的流量模型

设计之前先看清流量的形状。这是我做这套系统第一天就逼自己回答的问题：

特征	说明	架构含义
潮汐效应极强	晚 8 点 - 11 点是高峰，大促、球赛、爆款剧上线时流量成倍脉冲	弹性伸缩 + 削峰，按高峰容量做预案
读极多、写极少	EPG 节目单、Meta 元数据、Layout 下发占了 9 成以上流量	缓存优先，读路径尽量不打 DB
播放鉴权是超级热点	每次起播、切台都要鉴权取播放链接，QPS 随在线用户数线性涨	热点接口单独优化（缓存 + 短 TTL + 滑动续期）
设备在线心跳	app 轮询 session，百万级设备定时上报	心跳服务独立部署，写路径异步化
多品牌多租户	同一套系统服务多个品牌（巴西、俄语区等）	分库隔离爆炸半径，account_id 前缀区分品牌

这个流量形状——读多写少、晚间高峰、播放路径是生命线——决定了后面所有的架构取舍。

二、总体架构：一张图看清全貌

graph TB
    subgraph 终端
        STB["STB 机顶盒"]
        APP["移动 App"]
        WEB["Web / Portal"]
    end

    subgraph 接入层
        ELB["AWS ELB"]
        APISIX["APISIX 网关<br/>限流 Sentinel / WAF / 鉴权前置"]
    end

    subgraph 微服务层
        AUTH["vod-auth<br/>登录注册 / 账号 / 子账号"]
        SESS["common-session<br/>会话管理"]
        META["vod-meta-api<br/>元数据 / Layout / EPG"]
        PROF["profile<br/>观看历史 / 收藏 / 偏好"]
        CLOUD["vod-cloud<br/>个人网盘"]
        ROUTER["CloudRouter<br/>播放链接路由"]
        DRM["drmlicense<br/>DRM 鉴权与 license 下发"]
    end

    subgraph 数据层
        MYSQL["MySQL RDS<br/>按品牌分库"]
        REDIS["Redis Cluster<br/>Session / 验证码 / Meta 缓存"]
        METAREDIS["Meta 专用 Redis Cluster"]
        ES["Elasticsearch<br/>检索字段"]
        KAFKA["Kafka MSK<br/>Meta 同步 / 网盘同步"]
    end

    subgraph 内容侧
        STREAM["Streaming 流媒体"]
        CDN["CDN / Squid 边缘缓存"]
        CP["cloudProxy<br/>第三方网盘适配"]
    end

    STB --> ELB
    APP --> ELB
    WEB --> ELB
    ELB --> APISIX
    APISIX --> AUTH
    APISIX --> SESS
    APISIX --> META
    APISIX --> PROF
    APISIX --> CLOUD
    APISIX --> ROUTER
    ROUTER --> DRM
    ROUTER --> STREAM
    STREAM --> CDN
    STREAM --> CP
    META --> METAREDIS
    META --> ES
    AUTH --> MYSQL
    AUTH --> REDIS
    SESS --> REDIS
    CLOUD --> KAFKA
    META --> KAFKA

几个关键决策，后面逐章展开：

接入层：链路是 app -> ELB -> APISIX -> vod 微服务，限流用 Sentinel，网关做鉴权前置和 WAF。网关选型时我认真研究过 Netflix Zuul 2 从同步阻塞改异步非阻塞的历程——结论是网关本身绝不能成为瓶颈。我们体量没那么大，APISIX（底层同样是 Nginx + Lua 的高性能异步模型）已经够用。
服务拆分：按业务域拆（Auth / Profile / Meta / Cloud / Session），不是按技术层拆。领域拆分的完整过程在视频系统 DDD 实战里写过。
数据层：MySQL 按品牌分库（{brand}_account_db 等）；Redis 承载 Session、验证码、热点数据；Meta 用独立的 Redis Cluster 全量缓存，与业务缓存物理隔离；检索字段入 ES。
异步化：Kafka（MSK）只干两件事——Meta 同步管道和网盘同步，不滥用。这是我给自己立的规矩：每加一个 MQ topic 都要回答「同步调用为什么不行」。

三、高并发：把流量挡在离用户最近的地方

高并发的核心心法就一句：每一层都尽量把请求消化掉，别让它穿透到下一层。越靠近 DB 越贵。

3.1 网关层：第一道削峰闸

我们在网关层做了三件事：

限流：APISIX 自带 limit-req / limit-count 插件做粗粒度限流，Sentinel 做服务级细粒度熔断限流（现网组合就是「ELK + Skywalking + Sentinel（APISIX）」）。
鉴权前置：明显非法的请求（无 token、签名错误、UA 黑名单）在网关直接 401/403，不放行到业务服务。被攻击时这一层挡掉的流量经常比业务层处理的还多。
静态配置下发走 CDN：/ui/cfg/v1、/layout/v1 这类终端配置接口，内容变化频率低，直接走 CDN 缓存，源站只承担回源请求。

3.2 热点接口：播放鉴权链接的缓存设计

CloudRouter（播放源路由服务）是我手里最热的路径：每次起播都要按 logicStreamId 换真实的下载/播放链接。我做的设计非常直接：

graph LR
    A["App 起播请求<br/>logicStreamId"] --> B{"查 Redis"}
    B -- "命中" --> C["刷新 TTL 滑动续期<br/>直接返回链接"]
    B -- "未命中" --> D["查 MySQL 两表<br/>logic_stream + file_source"]
    D --> E["构建下载链接 DownloadBO<br/>link / fileSize / expired"]
    E --> F["写回 Redis"]
    F --> G["返回"]

三个细节值得说：

命中即续期（滑动 TTL）：热播内容的链接永不过期，冷内容自然淘汰——不需要人工预热。这个设计替我省掉了整个「热点内容运营」的麻烦。
缓存对象自带过期时间：链接本身有 expired 字段，客户端在链接到期前会重新请求，和缓存 TTL 是两层独立的过期机制，互不相信。
失败快速抛出：查不到直接抛业务异常，不做 fallback 到第三方存储的慢路径——播放链路每一毫秒都值钱。

3.3 多级缓存：L1 + L2

纯 Redis 方案在超热点 key 上依然会打满单个分片（新片上线当晚的 metaId 我真实遇到过）。为了解决这个问题我研究了 Netflix 的 EVCache——它的多副本加客户端本地缓存思路给了我启发，但我们体量用不上 EVCache 全套，于是我基于 Caffeine（L1 进程内缓存）+ Redis（L2）自己实现了一个两级缓存框架并开源，见我开发的 keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架，要点：

L1 短 TTL（秒级），扛住瞬时洪峰；
L1 失效消息走 Redis Pub/Sub 广播，保证多实例间 L1 不一致的窗口可控；
序列化用 Kryo，比 JDK 序列化小 3-5 倍。

3.4 写路径异步化：MQ 削峰

写少但集中的场景（新片上线批量导入 Meta、网盘大规模刷新）我全部走 Kafka：

graph LR
    A["vod-sync-dispatcher<br/>每 30 秒轮询上游片源"] --> B["Kafka MSK"]
    B --> C["vod-imdb-meta-sync<br/>元数据入 Redis + ES"]
    D["vod-cloud-sync-dispatcher"] --> B
    B --> E["vod-cloud-sync-worker<br/>刷新网盘"]
    F["http2Msk<br/>大数据 HTTP 回调转 MQ"] --> B
    B --> G["偏好计算<br/>you may like"]

生产者-消费者模型 + MQ 缓冲，让上游脉冲（片源方一次推几万条 meta）被摊平成消费者能吃得动的匀速流。当时的 MQ 选型过程见消息队列总结：RabbitMQ、Kafka、RocketMQ 与 Redis MQ。

另一个异步化的例子是我设计的转码调度：Quartz + DB 状态机驱动，每个片源转出 1-3 个分辨率、每个分辨率一个任务，用「动态归一化权重调度算法」分配执行器（priority = 客户权重 / 活跃任务数，兼顾多客户公平与并发槽位控制），30 分钟轮询任务进度。慢不要紧，稳和公平才要紧——这是典型的「离线任务用状态机换可靠性」。

四、高可用：假设一切依赖都会挂

我做高可用的两条心法，是从 Netflix 的工程实践里学来并在我们系统里反复验证过的：Design for failure（为失败而设计）和 Blast radius（控制爆炸半径）。落地到我们系统：

4.1 熔断、降级与兜底重试

熔断：我们早期直接用 Netflix 开源的 Hystrix 做熔断隔离，Hystrix 停更后迁移到 Resilience4j（网关层用 Sentinel）。工具换了，规则不变：下游超时率/错误率超阈值就熔断，快速失败，绝不线程排队等死。Hystrix 的线程池隔离思想对我们影响很大——核心链路（登录、起播）和非核心链路（埋点上报）的资源池必须分开。
降级而非失败：Meta 自动匹配失败时我定的策略是降级创建默认元数据，不影响文件源状态——内容能播永远比信息完美重要。
兜底重试：CloudAsset 的异常处理是我给全系统定的统一模式——3 次以内本轮调度重试，超过 3 次任务进失败状态，由独立的失败任务调度器兜底。关键设计点：主流程不被重试拖死，失败任务有独立通道排队消化，互不阻塞。

graph TB
    A["任务执行"] --> B{"成功?"}
    B -- "是" --> C["完成"]
    B -- "否, failCount+1"] --> D{"failCount ＞ 3?"}
    D -- "否" --> A
    D -- "是" --> E["status = fail"]
    E --> F["独立失败任务调度器<br/>定时扫描兜底重试"]
    F --> A

后来我把这类「一定要跑到」的可靠执行逻辑抽成了通用组件开源，见我开发的 KE Reliable Executor。

4.2 多租户隔离：分库就是隔舱

多品牌共享一套代码，但我在数据层做了物理隔离：

MySQL 按品牌分库（{brand}_account_db、{brand}_profile_db），公共数据在 vod_meta_db；
account_id 前缀区分品牌（MFC:11、TVELA:12、WAKA:13），应用层强制路由；
实体普遍带 env / vnoId 字段，logicStreamId 内嵌环境标识。

某品牌数据被打爆、误删、需要回滚时，影响面天然被限制在单库内。这就是水密隔舱——后来某品牌做数据订正时我真切体会到这个设计的价值。

4.3 依赖解耦：订阅模式

DRM 链路里我有个坚持：drmlicense 不直接依赖 Headend 和 drmencryptor 的在线接口，而是以订阅模式收 DrmContentInfoBO 和 ContentKeyBO，自己组装 logicalStream 与 PSSH 的关系。上游挂了，license 下发用已订阅到的数据照常工作。原因是算术：同步调用是可用性的乘法，异步订阅是加法——一个可用性 99.9% 的服务同步串依赖十个同样 99.9% 的服务，链路可用性就只剩 99% 了。

4.4 混沌工程：轻量版就够

Netflix 的 Chaos Monkey 是随机杀生产实例，逼所有服务习惯「邻居随时消失」。我评估后没敢直接上生产，但保留了这个思想的两个轻量实践：预发环境定期随机关停单个实例观察告警与自愈；每个季度做一次依赖演练（手动切断 Redis 从库、Kafka 单 broker），验证降级路径真的能用。我的原则：降级方案不演练就等于没有——每次演练几乎都能发现某条降级路径已经悄悄失效。

五、高性能：把钱花在读路径上

高性能章节不长，因为大部分事前面已经做了。补几个我做过的针对性的点：

优化点	做法
Meta 全量入内存	元数据全量进专用 Redis Cluster，终端 `/root/v1`、`/tree/v1` 等接口零 DB 访问
检索走 ES	只有关键检索字段入 Elasticsearch，不全量双写
播放内容边缘缓存	Streaming 前置 Squid + CDN，热点片源命中边缘节点，源站只承担回源（对应 Netflix Open Connect 的角色，我们用商用 CDN 实现）
大表治理	观看历史表现网 2-3 亿行，是我一直盯着的最大风险点：每天定时任务删 90 天前历史 + 按账号双表拆分（设备账号/普通账号）
JVM 与连接池	G1/ZGC、HikariCP 连接池按「连接数 = (核数 × 2) + 磁盘数」起步压测调优，慢 SQL 进 Skywalking 告警

原则：性能优化的 80% 是让请求根本到不了慢的地方，剩下 20% 才是调参数。

六、缓存一致性与缓存高可用

这是全文我最想细说的一章。缓存是性能的来源，也是我事故最多的地方。

6.1 一致性策略：先写 DB，后删缓存

vod-auth 的账号数据我用的是标准的 Cache Aside + 写后删除：先写 DB，成功后再删缓存，下次读时回源重建。为什么选「删除」而不是「更新」？我想清楚过：「先写 DB 再删缓存」只有在「读线程恰好踩着写间隙回源了旧值」的极端窗口才会短暂不一致，而「更新缓存」在并发双写下会乱序覆盖出脏数据。删除的失败模式是 miss（回源一次，便宜），更新的失败模式是脏数据（播错内容，贵）。

对一致性要求更高的场景（套餐权益、付费状态），我在删除之上再加一层：

延迟双删：写 DB → 删缓存 → 延迟 N 秒 → 再删一次，兜住间隙回源；
或用 MQ 发缓存失效消息，由消费者负责删除 + 失败重试，把「删缓存失败」这个尾巴也闭环掉。

6.2 缓存三大经典问题的组合拳

问题	我遇到的场景	解法
穿透	恶意刷不存在的 metaId / accountId	布隆过滤器拦截 + 空值短 TTL 缓存（30 秒）
击穿	爆款剧上线，热点 key 过期瞬间	逻辑过期 + 互斥重建：value 里带逻辑过期时间，过期后只放一个线程回源，其余返回旧值
雪崩	大量 key 同 TTL 同时到期	TTL 加随机抖动（基础值 ± 20%）+ Redis Cluster 多主分摊

逻辑过期方案有个工程细节：回源重建要用分布式锁（Meta 绑定我用的就是分布式锁，获取失败快速失败、重新调度），且锁的 TTL 必须大于回源耗时，finally 里释放——我在 CloudAsset 方案里专门写了「任何异常都会释放分布式锁、清除 ThreadLocal」，这是血泪经验，锁泄漏一次就够排查一晚上。

6.3 缓存自身的高可用

Redis Cluster 多主 + 从：Meta 缓存我用独立集群，和 Session/验证码的集群物理隔离——Meta 集群被打挂不影响用户登录。
多级缓存兜底：Redis 整体不可用时，L1（Caffeine）还能扛住读过期窗口，服务降级而不是全灭。
从 EVCache 学到的运营观：我研究 Netflix EVCache 时最大的收获不是 memcached 本身，而是他们把缓存当成 tier-0 服务运营——独立容量规划、独立监控、独立 SLO。我照这个思路给缓存集群配了和业务服务同级别的告警与容量评审。缓存在高并发系统里不是优化项，是一级基础设施——这点很多团队要到出事才懂，我庆幸自己学得早。

七、零信任安全与必要防御

7.1 零信任：永不信任，始终验证

我们的安全体系是在几次整改后逐步按零信任思路重建的——内网不再等于可信，每一次调用都要验证身份，不论它来自哪里。落地到我的系统，是这几件事：

用户侧：accessToken（JWT，sub = accountId）+ 播放票据 tk12（内含 expireTime / accountId / streamId，由平台密钥签发）。App 起播时两个都要验，token 验「你是谁」，tk12 验「你能不能播这条流、能播到什么时候」。
设备侧：账号卡与设备绑定（ac_device_binding），device_limit 限制并发设备数，挤掉盗号共享的盈利空间。
服务间：内部接口（/internal-api/...）不走公网网关，服务间调用带服务身份凭证。我评估过 mTLS + SPIFFE 这套工作负载身份方案（Netflix 零信任改造用的就是这条路），对我们体量偏重，最终落地为「内部接口不暴露 + 调用方白名单」，等规模上来再升级。
最小权限：cloudProxy 是我专门做的收敛层——把对第三方网盘（Mega 等）的所有访问收敛成一个适配层，只暴露 checkPassword 和 getDownloadLink 两个接口，业务服务根本不接触第三方凭证。

7.2 一次真实的安全整改：网盘密码泄露

这是我亲手推动的整改，值得完整复盘。背景：网盘打包工具生成的加密网盘包里含账号 + 加密后的登录密码，加解密密钥一旦泄露，所有网盘账号密码全部泄露。

整改分两步走：

第一步，密码不落地。 新网盘包不再写密码，改为写入与网盘账号一一对应的 shareKey（UUID）。导入时只校验 shareKey 一致性，通过后把网盘与用户关联。按网盘包 version 字段区分新老包走新旧两条校验逻辑，平滑迁移——存量兼容是安全改造里最容易被低估的工作量，这一步我花的精力比新逻辑本身还多。

第二步，密钥体系升级。 对称加密改 RSA 非对称加密：

graph TB
    A["CP / Reseller<br/>只拿到 RSA 公钥"] --> B["公钥加密网盘包<br/>公钥泄露也无法解包"]
    C["VNO 上传私钥<br/>加密保存于平台 pkg_rsa_key 表"] --> D["导入时按 VNO 查私钥"]
    B --> E["网盘包带签名<br/>含 pkgId + keyId"]
    E --> D
    D --> F["先验签再解密<br/>解密成功才关联用户"]

配套我设计的密钥轮换机制：平台同时最多两个 Key 生效；更新时旧密钥先进入最长 30 天缓冲期，再生成新密钥对；存在生效中的旧密钥则不允许再次更新——防止轮换频率失控导致历史包无法解密。

另外扫码登录链路我也推动做过同类加固：扫码站点从 S3 静态托管（明文登录）迁移到托管服务并接入加固方案，鉴权统一收口到 vod-auth。

7.3 接口消息体加密：HTTPS 之上的第二道锁

有人会问：全站都上 HTTPS 了，为什么还要在应用层再加密一次消息体？我的理由有三个，都来自实际教训：

HTTPS 防不住终端侧的抓包。Charles/Fiddler 挂个代理证书，App 和网关之间的明文报文一览无余——协议字段、业务参数、token 用法全暴露。C 端 App 发出去的那一刻起，客户端环境就不可信。
HTTPS 到网关就终止了。TLS 在 ELB/APISIX 卸载后，内网转发的是明文；零信任的原则是内网也不可信，敏感报文在网关之后依然应该处于加密状态。
IPTV 场景的特殊性：播放鉴权、充值、账号接口一旦被逆向出报文格式，黑产就可以脱离 App 直接伪造请求刷接口。

我设计的方案是 TLS 为底线 + 应用层 AES 加密消息体，核心链路如下：

graph LR
    A["App 启动<br/>ECDH 密钥协商<br/>网关公钥经 SSL Pinning 校验"] --> B["得到会话密钥 sessionKey<br/>按 session 绑定"]
    B --> C["业务请求<br/>AES-256-GCM 加密 body"]
    C --> D["明文头带 token + 时间戳<br/>+ nonce + HMAC 签名"]
    D --> E["网关统一解密过滤器<br/>验签名 / 验时间窗 / 验 nonce"]
    E --> F["业务服务收到明文<br/>响应同样加密回传"]

工程上的几个取舍，都是试出来的：

密钥协商用 ECDH，不用硬编码密钥。早期图省事在 App 里内置过 AES 密钥，App 被反编译后全线失守，改成登录/启动时 ECDH 动态协商、密钥绑定 session、服务端定期强制轮换。SSL Pinning（证书固定）挡住大部分中间人代理，让 ECDH 协商本身不被劫持。
AES-256-GCM 而不是 CBC：GCM 自带完整性校验（AEAD），加密和防篡改一次完成；密钥 nonce 绝不复用。
头部明文、body 加密：token、时间戳、nonce、签名放明文头里，网关不解密就能先做限流和鉴权前置；body 整体加密，解密收敛在网关的统一过滤器里，业务服务无感知——加解密逻辑散落进每个 Controller 是维护灾难。
不是所有接口都加密。EPG、Meta 这类公开内容接口只走 HTTPS + 签名；登录、充值、播放鉴权、账号操作这些敏感接口才上消息体加密。全量加密的 CPU 成本和排查问题的痛苦不成比例——加密后的日志排障要靠专门的脱密工具，这也是成本。
绝不自研算法。所有原语都用成熟实现（AES-GCM、ECDH、HMAC-SHA256），自己拼协议可以，自己造算法不行。

7.4 必要防御：防攻击清单

攻击面	我们的防御手段
接口刷量 / CC 攻击	网关限流 + Sentinel 熔断；登录、验证码接口按 IP + 账号双维度计数
短信/邮件轰炸机	验证码存 Redis 带 TTL，验证成功后立即删除防重放；单账号/单 IP 频次限制
重放攻击	请求带时间戳 + nonce，token 短过期
抓包 / 中间人	HTTPS + SSL Pinning + 敏感接口消息体加密（见 7.3）
越权访问	tk12 绑定 `accountId + streamId`，换账号播放直接鉴权失败
篡改网盘包	RSA 签名验签，验签不过不解密
撞库 / 盗号	登录失败计数锁定（`account_black_list`）、设备绑定、子账号体系隔离
敏感信息外泄	交接文档脱敏（我们的交接文档里曾出现明文环境密码，是我抓出来的典型反面教材）；日志脱敏；DB 密码字段只存哈希

7.5 DRM：内容安全的最后一道门

DRM 链路的安全设计我同样按零信任思路做：ContentKey 由独立密钥服务（drmencryptor）管理，先查缓存没有再向外部 DRM 厂商申请并落库缓存；播放优先走离线 license（有缓存用缓存），PSSH 异常才降级在线 license。license 本身带过期时间，App 本地不持久化密钥。系统支持 Goose DRM 与 Multi-DRM（Widevine）切换，切换动作就是删旧流加新流——密钥体系与业务流解耦，这个设计让后来的 DRM 厂商迁移几乎没动业务代码。

八、可观测性：没有度量就没有高可用

我们的现网组合：ELK 日志 + Skywalking 链路追踪 + Prometheus/Grafana 指标 + Nacos 配置中心，每个子系统独立 ES index。

我压测过的容量数据（v7.16 集群）：只写日志约 11 万条/秒，只写 Skywalking 约 2 万条/秒，混合写时日志 6 万 + 链路 1 万/秒。

血泪教训：周一高峰 Skywalking 曾出现 4 小时写入延迟，日志量增长也让 Logstash 排队。事后我立了两条规矩：

日志与链路采样分离：高峰期链路数据降采样，保住日志；两者绝不能互相拖死。
本地日志保留 30 天，crontab 定时清理——磁盘写满导致的 ELK 雪崩比业务故障还常见。

我还坚持一点：告警要打在用户可感知的指标上（起播成功率、鉴权失败率、链接过期率），而不是只打 CPU 内存——机器好好的但用户看不了，是最尴尬的监控盲区。服务间的依赖关系复杂到一定程度后，「告警来了不知道谁影响了谁」会成为新问题，Netflix 为此专门做过一套服务拓扑系统，我研究过它的实现并整理了笔记：Netflix 服务拓扑系统笔记。

九、总结：一张 checklist

维度	我采用的核心手段	用到的 Netflix 开源组件 / 实践
高并发	网关限流、缓存优先、MQ 削峰、多级缓存	Zuul 2 异步化思想、EVCache 启发 keCache
高可用	熔断降级、失败兜底调度器、多租户分库隔离、订阅模式解耦	Hystrix（后迁 Resilience4j/Sentinel）、Chaos Monkey 轻量版
高性能	Meta 全量入内存、ES 检索、CDN/Squid 边缘缓存、大表治理	Open Connect 的边缘缓存角色
缓存一致性	先写 DB 后删缓存 + 延迟双删、逻辑过期防击穿、随机 TTL 防雪崩	EVCache 的缓存运营观
零信任	双票据鉴权、设备绑定、内部接口白名单、最小权限适配层	零信任改造思路（mTLS/SPIFFE 评估后暂缓）
攻击防御	网关 WAF/限流、验证码防重放、RSA 验签、黑名单、敏感接口消息体加密	—
可观测	ELK + Skywalking + Prometheus，日志链路采样分离	服务拓扑系统的思路

最后一句实话：这套架构没有一样是发明出来的，全部是踩坑踩出来的。网盘密码泄露、Skywalking 四小时延迟、2-3 亿行的历史大表——每个设计决策背后都有一次事故或一次险些事故。Netflix 的开源组件和博客帮我少踩了很多坑，但终究要自己踩过才知道坑有多深。架构师的职责不是画出完美的图，而是让每个坑只踩一次。

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

Fri, 02 Oct 2026 19:00:00 +0800

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

目标读者：四类人——

后端/数据工程师：要上手 Spark 或 Flink，需要心智模型加能跑的代码（看"基础"两节，附 Java API 示例）；

架构师/技术负责人：在给数据平台选型，想知道两者的边界和硬件投入（看"血统对比"“算力规格"和"选型决策”）；

运维/SRE：要看监控什么、出事怎么处理（看"监控"和"故障与恢复"）；

正在踩坑的人：直接翻到文末两家的避坑清单。

阅读前提：了解 Kafka 是什么即可，不需要大数据背景。

前两篇讲推荐 Feed 架构时，Spark 和 Flink 反复出现：Spark 做离线训练，Flink 做近线特征。有读者问：Spark 不就是内存分布式计算吗，和 Flink 功能差不多？

看着像，血统完全不同。这篇把两者各自的基础概念讲清，然后放进一家类 Netflix 的视频公司里看它们分别干什么活，最后附上两家的避坑指南。

Spark 基础：批处理血统的内存计算引擎

Spark 在 2010 年前后接棒 Hadoop MapReduce，核心卖点一句话：把中间结果放内存，迭代计算不用反复落盘。MapReduce 每轮迭代都要读写 HDFS，Spark 把数据缓存进内存，迭代型任务（机器学习训练要扫数据几十遍）快了十到一百倍。

三个核心概念：

RDD / DataFrame：数据被抽象成分布式集合，切成分区（partition）摊在集群各节点上。RDD 是原始 API，现在日常用的是 DataFrame——带结构（schema）的表，配合 Spark SQL 直接写 SQL。
DAG 执行：你对数据做的一串操作（filter、join、groupBy）不会立即执行，而是攒成一张有向无环图；遇到"要结果"的动作（count、写盘）才触发，调度器把图切成 stage、分发执行。惰性求值让引擎有机会做全局优化。
Shuffle：数据按 key 重新分发的操作（groupBy、join 都会触发），是 Spark 作业里最贵的一步——数据要跨节点搬运、序列化、落盘。后面避坑指南里一半的坑都和它有关。

血统决定视角：在 Spark 眼里，数据是一批一批的——有界的、静态的数据集。它的流处理能力（Structured Streaming）是后来在批的骨架上加的：把数据流切成一小批一小批，攒一批算一次（micro-batch）。延迟天然是秒级到分钟级。

上手：一个 ETL 作业的 Java 写法。场景：把昨天的播放原始日志清洗成"每视频日播放量"聚合表：

SparkSession spark = SparkSession.builder()
        .appName("play-events-etl")
        .getOrCreate();

// 读：数据湖里昨天的原始播放事件（分区表）
Dataset<Row> events = spark.read()
        .parquet("s3://warehouse/raw/play_events/dt=2026-10-01/");

// 处理：过滤脏数据、按 event_id 去重、换算播放分钟数
Dataset<Row> cleaned = events
        .filter("duration > 0 AND user_id IS NOT NULL")
        .dropDuplicates("event_id")
        .withColumn("play_minutes", col("duration").divide(60));

// join 内容维度表补标题和类目（小表广播，避免 shuffle）
Dataset<Row> enriched = cleaned
        .join(broadcast(spark.read().parquet("s3://warehouse/dim/videos/")), "video_id");

// 聚合出结果并写回数仓（coalesce 控制输出文件数，防止小文件）
enriched.groupBy("video_id", "category")
        .agg(count("*").alias("plays"), sum("play_minutes").alias("total_minutes"))
        .coalesce(4)
        .write()
        .mode("overwrite")
        .parquet("s3://warehouse/agg/daily_video_plays/dt=2026-10-01/");

注意这段代码提交后什么都不会立刻发生——filter、join、groupBy 只是在攒 DAG，最后的 write() 这个动作才触发真正的执行。这就是前面说的惰性求值。

这段代码里还有一件"看不见"的事值得说破：分区是自动切的，你全程没有指定过它。分区的三个来源：

读入分区由文件决定：读 parquet 时 Spark 按文件切块，spark.sql.files.maxPartitionBytes（默认 128MB）决定每块多大，每块一个分区。路径里的 dt=2026-10-01/ 本身就是物理分区，Spark 只扫这一天的目录，其余按分区裁剪跳过；
shuffle 后分区由配置决定：groupBy 触发数据重分发，之后的分区数由 spark.sql.shuffle.partitions 控制，默认 200——小作业跑完写出 200 个小文件，罪魁祸首就是它；
手动干预只有两个 API：repartition(n) 重新洗牌（会产生一次 shuffle，贵），coalesce(n) 只合并不洗牌（便宜）。上面代码写出前的 coalesce(4) 就是故意把默认的 200 个分区合并成 4 个输出文件。

那"拉起几十台机器并行计算"体现在哪？答案是：不体现在代码里，体现在物理执行里。 同一份代码在一台笔记本上（local 模式）和一百台机器上跑，一行都不用改——分布式是部署特征，不是代码特征。看这段 ETL 提交到集群时实际发生什么：

spark-submit \
  --class com.example.PlayEventsETL \
  --master yarn \
  --num-executors 50 \        # 拉起 50 个 executor 进程，分布在集群各节点
  --executor-cores 5 \        # 每个 executor 5 核
  --executor-memory 20g \
  --driver-memory 8g \
  app.jar

这里的 app.jar 是你自己的应用代码打包产物：前面那段 ETL 的 Java 代码用 Maven/Gradle 编译，打成包含全部依赖的 fat jar（Maven 用 shade 插件、Gradle 用 shadow 插件），--class 指定里面的入口类。提交时这个 jar 被上传到集群，driver 拿到后把代码分发到各 executor——executor 上跑的 task，执行的就是这个 jar 里的字节码。所以 Spark 作业的交付物就是一个 jar：改代码 = 重新打包重新提交。

生产环境里谁来"敲"这个 spark-submit？ 凌晨两点跑批不是值班同学手动敲命令。业界的提交方式按层次分：

SparkLauncher：Spark 官方自带的 Java API，在 Java 进程里编程式提交作业，还返回句柄可轮询状态——自研平台的标准做法：

SparkAppHandle handle = new SparkLauncher()
        .setAppResource("app.jar")
        .setMainClass("com.example.PlayEventsETL")
        .setMaster("yarn")
        .setConf(SparkLauncher.EXECUTOR_MEMORY, "20g")
        .startApplication();   // 异步返回，拿 handle 跟踪作业状态

Apache Livy：把提交做成 REST 服务——HTTP POST 一个 jar、轮询状态、拉日志。Web 系统里嵌入 Spark 提交能力的标准件；
调度系统：Apache DolphinScheduler、Airflow 这类工作流平台，管的是"凌晨 2 点跑 ETL、成功了再跑模型训练"这种依赖编排，底层调的仍然是 spark-submit 或 Livy；
云厂商 API：EMR Steps、Databricks Jobs 这类托管服务，提交动作变成一个云 API 调用。

顺带纠个常见的偏：Apache Commons 系列里没有 Spark 专用提交工具——Commons Exec 只是通用的外部进程包装器，有些自研平台拿它包 spark-submit 命令行（拿退出码、控超时），能用但不是主流。想在 Java 里提交作业，正路是 SparkLauncher 或 Livy。

50 个 executor × 5 核 = 250 个任务槽位同时干活，1TB 堆内存的总池子。作业跑起来后，逻辑计划被拆成物理 stage，每个分区对应一个 task，task 被调度到空闲槽位上：

flowchart TD
    A["Stage 1 读取+过滤<br/>2TB parquet 按 128MB 切块<br/>约 16000 个分区 = 16000 个 task"] --> B["Stage 2 join<br/>维度表广播到每个 executor<br/>无 shuffle"]
    B --> C["shuffle 重分发<br/>按 video_id 搬运数据"]
    C --> D["Stage 3 聚合+写盘<br/>200 个 task 各自聚合自己那份"]
    A -.->|"250 个槽位并发<br/>16000 个 task 分批消化"| A

几个数字感：

一天 100 亿条播放事件约 2TB parquet，切成约 16000 个分区，每个分区一个 task——250 个槽位并发，分批消化完这 16000 个 task，这就是"拉起多个节点"的物理形态；
谁挂了谁重试：某个 executor 宕机，它跑过的 task 在别的节点上按血统重算，作业整体不停；
想更快就加机器：--num-executors 100，槽位翻倍，16000 个 task 消化速度就近似翻倍——这就是水平扩展：代码不变，吞吐随机器数线性涨（直到被 shuffle 或存储 IO 卡住）。

ALS 训练是同一个道理，只是把"一批 task"换成"几十轮、每轮一批 task"：每一轮迭代都是一次全集群的分布式计算，中间结果留在内存里不落盘——这正是 Spark 相比 MapReduce 快的根源。

所以读 Spark 代码的正确姿势是：代码是蓝图，集群按分区把蓝图实体化成成千上万的 task。你在代码里看不到"多节点"，正如你在建筑图纸上看不到施工队——但图纸上的每一堵墙，都会变成某个工人在某个脚手架上的具体动作。

机器学习也一样是 DataFrame 风格的 API。Spark MLlib 里自带 ALS（交替最小二乘，就是矩阵分解），拿交互数据训练推荐模型只要几行：

ALS als = new ALS()
        .setMaxIter(10)          // 迭代轮数：交替优化用户矩阵和物品矩阵
        .setRegParam(0.1)        // 正则化，防过拟合
        .setUserCol("user_id")
        .setItemCol("video_id")
        .setRatingCol("score")   // 行为强度：完播=3 点赞=2 点击=1
        .setColdStartStrategy("drop");

ALSModel model = als.fit(playEvents);
// 输出用户向量和物品向量，供线上召回使用
model.userFactors().write().parquet("s3://warehouse/rec/user_factors/");
model.itemFactors().write().parquet("s3://warehouse/rec/item_factors/");

fit() 跑完，userFactors 就是前面推荐架构文章里说的"每个用户一个几百维的向量"——概念和代码在这里接上了。

Flink 基础：流处理血统的计算引擎

Flink 的出发点反过来：世界本质是流，批只是流的特例（有界流）。数据逐条进来逐条处理，毫秒到秒级延迟。

四个核心概念：

事件时间与水位线（event time & watermark）：事件"发生的时间"和"到达系统的时间"经常不同（用户手机离线两小时，数据才补传上来）。Flink 允许按发生时间计算，水位线是"我认为早于 t 的事件基本都到齐了"的声明，晚到超过容忍度的数据进侧输出流。这是流处理区别于批处理最本质的概念——批处理里根本没有"数据晚到"这个问题。
状态（state）：算子可以持有状态，比如"最近一小时的点击数"。状态按 key 分布在各并行实例上，大作业可以到 TB 级。
checkpoint / exactly-once：定期给所有算子的状态做全局一致性快照，故障后从快照恢复，保证每条数据恰好被计算一次。
savepoint：手动触发的快照，用于升级和扩缩容——代价是"停作业、改并行度、从快照重启"，这也是之前那篇 Netflix 给 Flink 做自动扩缩容那么难的原因。

上手：实时热榜的 Java 写法。场景：统计每个视频最近 10 分钟的播放量，每分钟刷新一次（滑动窗口）：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 每 60 秒做一次 checkpoint，故障恢复就回到最近一次快照
env.enableCheckpointing(60_000);

// 数据源：Kafka
KafkaSource<PlayEvent> source = KafkaSource.<PlayEvent>builder()
        .setBootstrapServers("kafka:9092")
        .setTopics("play-events")
        .setGroupId("hot-ranking")
        .setValueOnlyDeserializer(new PlayEventSchema())
        .build();

// 关键一步：声明用事件时间，容忍 5 分钟乱序
// 手机离线两小时补传的数据，仍然算回"发生那一刻"的窗口
WatermarkStrategy<PlayEvent> wm = WatermarkStrategy
        .<PlayEvent>forBoundedOutOfOrderness(Duration.ofMinutes(5))
        .withTimestampAssigner((event, ts) -> event.getEventTime());

DataStream<PlayEvent> events = env.fromSource(source, wm, "kafka-play-events");

events
        .keyBy(PlayEvent::getVideoId)                                  // 按视频分流
        .window(SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)))
        .aggregate(new PlayCounter())                                  // 窗口内计数
        .addSink(new RedisSink<>());                                   // 结果写 Redis，榜单服务读

这段代码里藏着 Flink 思维方式的全部要点：keyBy 决定状态按什么分发（每个 video_id 一份计数状态），window 按事件时间划分窗口而不是按到达时间，水位线声明"晚到 5 分钟以内的数据我等你"。

状态的 TTL 管理（避坑指南第一条）在代码里长这样：

StateTtlConfig ttl = StateTtlConfig.newBuilder(Time.days(7))
        .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)   // 写入时刷新过期时间
        .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
        .build();

ValueStateDescriptor<Long> desc = new ValueStateDescriptor<>("play-count", Long.class);
desc.enableTimeToLive(ttl);   // 状态 7 天不活跃自动清理，防止无限膨胀

部署：对应的启动命令。Flink 的交付物同样是一个 fat jar，但启动命令和 Spark 有一个本质区别——spark-submit 起的作业算完就退出，flink run 起的作业是常驻的（流处理理论上永不结束）：

# 提交常驻流作业到 YARN（跑在 K8s 上则换成 -t kubernetes-application）
flink run-application \
  -t yarn-application \
  -c com.example.HotRankingJob \      # main 入口类
  -p 64 \                             # 全局并行度：占用 64 个 slot
  hot-ranking.jar

# 升级代码或改并行度的标准动作：先打 savepoint，再从快照恢复
flink stop <jobId> --savepointPath s3://checkpoints/hot-ranking/
flink run-application \
  -t yarn-application \
  -c com.example.HotRankingJob \
  -s s3://checkpoints/hot-ranking/savepoint-abc123 \   # 从这份状态恢复
  -p 128 \                                             # 并行度可以顺便改
  hot-ranking.jar

对照着看两套命令的分工：Spark 用 --num-executors / --executor-cores 申请资源（因为要装下一批又一批的 task）；Flink 用 -p 声明并行度（因为作业结构固定，并行度就是常驻 worker 数）。而 -s 恢复 savepoint 这个参数是 Flink 独有的——Spark 批作业没有"带着状态继续跑"的概念，它每次都是从头算一批新的。

生产环境谁来提交 Flink 作业？ 和 Spark 不完全对称——Flink 没有一个像 SparkLauncher 那样常用的官方 Java 提交 API，业界的答案按部署形态分：

Flink Kubernetes Operator（当前主流）：作业定义成一份 FlinkDeployment YAML（K8s 自定义资源），kubectl apply 即提交。Operator 托管整个生命周期：拉起、监控、升级时自动做 savepoint 并从快照恢复——上面手动敲的 flink stop --savepointPath 那套动作，它全自动；
Apache StreamPark（原 StreamX）：作业管理平台，Web 界面管理 jar 上传、配置、启停和 savepoint，国内团队用得多；
Ververica Platform：Flink 创始团队公司的平台产品（有社区版）；
JobManager REST API：直接 HTTP 上传 jar 再触发 run——Flink Web UI 的提交走的就是它，自研平台想自己包一层时用；
YARN 模式：就是上面那条 flink run-application 命令，CLI 直连，老集群常见。

趋势很明确：K8s Operator 是官方主推方向，新平台直接从这里起步，别再自建提交流程。

血统对比：一张表

维度	Spark	Flink
数据观	有界批处理是本质，流是微批模拟	无界流是本质，批是有界流特例
典型延迟	秒级 - 分钟级	毫秒 - 秒级
状态管理	弱（流场景下才需要，能力有限）	一等公民（keyed state、TB 级）
事件时间	支持，但受微批粒度约束	原生设计，水位线机制成熟
生态主场	数仓 SQL、MLlib、Python 数据科学	实时管道、实时数仓、CEP
思维负担	低：写 SQL / DataFrame 像写单机代码	高：要时刻想着时间、状态、背压

一句话记忆：Spark 把流当批做，Flink 把批当流做；前者简单但延迟高，后者精确但心智负担重。

视频公司里各干什么活

场景设定：一家类 Netflix 的视频公司，几亿用户，每天产生百亿级行为事件。同一条数据流，两种引擎各管一段：

flowchart LR
    A["用户行为事件<br/>播放 暂停 点赞 卡顿"] --> B["Kafka 事件总线"]
    B --> C["Flink 实时链路<br/>秒级生效"]
    B --> D["落地数仓<br/>Iceberg 数据湖"]
    D --> E["Spark 离线链路<br/>小时级 天级"]
    C --> F["在线服务<br/>画像 热榜 监控告警"]
    E --> G["模型 报表 实验分析"]

Flink 的活——“这件事现在就要知道”：

实时画像更新：用户每看一条视频，行为事件进 Kafka，Flink 作业滚动更新"最近 N 次行为的加权兴趣向量"，秒级生效。下一刷推荐就变。
实时热榜：按事件时间滑动窗口统计各视频的播放增速，每分钟刷新 Trending 榜单。注意必须用事件时间——用户手机离线补传的数据不能算到"现在"。
播放质量监控（QoS）：卡顿率、首帧时间、播放失败率按地区/运营商/客户端版本实时聚合，超过阈值就告警。某运营商骨干网抽风，值班同学三分钟内就该收到电话。
实时风控：同一设备十分钟内播放 200 个视频？异常刷量实时拦截，不等第二天对账。

Spark 的活——“这件事今天算完就行”：

数仓 ETL：Kafka 落地到 Iceberg 的原始日志，Spark 按天清洗、去重、补维度（join 用户表、内容表），产出标准明细表。全公司数据分析的地基。
推荐模型训练：拿过去 30 天的用户-内容交互矩阵，训练排序模型（交互矩阵怎么变成用户偏好，详见推荐 Feed 架构里"用户偏好怎么算出来"一节）。训练要扫数据几十遍，正是 Spark 内存迭代的甜点场景。
经营报表：每日播放时长、新增会员、留存率——管理层早上九点要看的看板，Spark 凌晨跑批产出。
A/B 实验分析：实验组对照组的指标对比、显著性检验，数据科学家写 Spark SQL + Python 完成。

同一条数据的两次旅程：用户晚上 8 点点开一条视频——这个事件两秒内被 Flink 消费，画像更新、热榜计数、质量监控全部生效；凌晨 2 点，同一个事件（已从 Kafka 落盘）被 Spark 的 ETL 作业清洗进数仓，早上 6 点进入模型训练数据。实时链路管"现在"，离线链路管"沉淀"，谁也别抢谁的活。

算力规格：硬件怎么配

先给结论再讲推理：大数据集群的钱主要花在内存和 SSD 上，CPU 反而不是瓶颈的主角。

Spark 节点的典型规格（按 2026 年的行情）：

角色	规格	要点
Worker 节点	32-64 核 CPU、128-256GB 内存、4-8 块 NVMe SSD 做本地 shuffle 盘、10-25Gbps 网卡	shuffle 数据写本地盘，SSD 比内存更影响大 join 的稳定性
Executor 切分	每个 executor 4-5 核、16-24GB 堆内存	一台 32 核 128GB 的机器切 5-6 个 executor；executor 太大 GC 停顿长，太小则 broadcast 等开销被重复多份
Driver	8-16GB 内存起步	调度 + 收集元数据；大 job 的执行计划、broadcast 变量都压在这里

Flink 节点的典型规格：

角色	规格	要点
TaskManager	8-16 核、32-64GB 内存、本地 NVMe SSD 必须有	大状态用 RocksDB state backend，状态落在本地盘，SSD 的随机读写直接决定状态访问性能
slot 划分	slot 数 = CPU 核数（1:1 起步）	并行度不能超过总 slot 数；一个 slot 一个线程，避免 CPU 争抢
JobManager	4 核 8GB 起步，HA 模式至少两个	协调 checkpoint，不搬数据，轻
checkpoint 存储	S3 / HDFS / 对象存储	快照不占本地盘，占的是远程存储和网络带宽

容量估算的例子，把数字走一遍：假设行为事件峰值 10 万条/秒、单条 1KB，实时链路（画像 + 热榜 + 监控）合计维护 500GB 状态。

网络：10 万 × 1KB = 100MB/s，25Gbps 网卡毫无压力——数据管道的瓶颈很少是网络；
状态：按单个 TaskManager 管理 64-128GB RocksDB 状态比较稳妥的经验值，500GB 状态需要 4-8 台 TaskManager；
CPU：窗口聚合类作业每条事件的计算很轻，10 万条/秒摊到 64 个核上每核每秒 1500 条，富余；
所以这套链路 8 台"16 核 64GB + NVMe"的机器跑得很从容，再留 30% 峰值冗余即可。

反过来，凌晨的 Spark 训练作业要扫 30 天 × 百 TB 级日志，它的瓶颈是 shuffle 吞吐和内存，机器数量按"凌晨 6 点前必须跑完"倒推——离线集群的规格是被截止时间定义的。

监控：两套引擎各看什么

Spark 监控的主入口是 Spark UI（每个作业一个 Web 界面），配合 Prometheus 抓指标。值班时按这个顺序看：

Stages 页：哪个 stage 慢、shuffle read/write 多大——shuffle spill（内存放不下溢写磁盘）是性能第一警报；
Tasks 页的任务时长分布：p50 是 2 分钟、max 是 40 分钟 → 数据倾斜，不用怀疑；
Executors 页：GC 时间占比超过 10% 说明内存配置或数据结构有问题；executor lost 频繁出现说明节点或内存超卖；
Event Log 持久化到 HDFS/S3，作业挂了也能回放分析——务必开启，默认不一定开。

Flink 监控的主入口是 Web UI + 指标上报（Prometheus reporter），核心看四组：

指标	看什么	告警阈值参考
背压 `backPressuredTimeMsPerSecond`	哪个算子被顶住	持续 >50% 就要查
checkpoint `lastCheckpointDuration` / `lastCheckpointSize`	快照耗时和体积增长趋势	耗时接近间隔、体积周环比暴涨都是事故前兆
Kafka 消费 lag（`records-lag`）	消费追不上生产 = 延迟在堆积	持续增长 10 分钟告警
水位线延迟	事件时间推进是否停滞	水位线不动 = 窗口永远不触发

告警的验收标准只有一条：每个告警都必须对应一个动作。“CPU 高"不是告警，“热榜作业 Kafka lag 连续增长 10 分钟"才是——前者看了也不知道干嘛，后者直接指向扩容或查背压。

故障与恢复：出事时的标准动作

Spark 的故障模型是"重算”，血统里带着 MapReduce 的基因：

task 失败 → 自动重试（默认 4 次，spark.task.maxFailures 可调），重试时只重算这个分区；
executor 挂了 → 它算过的分区按 lineage（血统）重新算——RDD 天生记得自己从哪算来的，这就是当年 RDD 论文的核心思想；
个别 task 特别慢（straggler）→ 开推测执行（spark.speculation=true），同样的任务在别的节点再跑一份，谁先完用谁；
driver 挂了 → 最麻烦，批作业整体重跑；所以重要的 ETL 要幂等（写分区用 overwrite 而不是 append），重跑不出脏数据。

Flink 的故障模型是"回滚”，回到最近一次 checkpoint：

TaskManager 挂了 → 作业自动从最近的成功 checkpoint 恢复，Kafka source 回到快照时记录的 offset 重新消费，配合两阶段提交的 sink 保证恰好一次；
重启策略别用默认：生产上推荐 failure-rate（10 分钟内允许失败 N 次，超过才放弃）配合重启间隔，防止依赖的 Kafka/Redis 抖动时作业无脑高频重启把对方打垮；
JobManager 挂 → 必须配 HA（ZooKeeper 或 K8s 选主），否则协调者单点；
checkpoint 是自动的、savepoint 是手动的：代码升级、改并行度必须先做 savepoint 再停作业，从 savepoint 启动新版本。

一个标准故障处置剧本（实时画像更新作业 lag 暴涨）：

看 Flink UI 背压页——找到链条上第一个变红的算子；
是某个下游慢（比如 Redis 抖动）→ 修下游，作业自己追上来；
是数据洪峰 → 临时调大并行度（savepoint → 重启 → 恢复），或者干脆等洪峰过去，Kafka 里的数据丢不了；
恢复后盯 Kafka lag 回落到正常水位，确认 checkpoint 恢复绿色；
事后复盘：这次故障该变成哪条告警规则？

注意底气来自哪里：Kafka 保留了原始事件，Flink 保留了状态快照——前者保证"数据丢不了"，后者保证"进度丢不了"。两个都在，故障就只是插曲不是事故。

Kafka + Flink 组合：失败后到底会不会重复、会不会丢

这是面试和值班都绕不开的问题，拆开两个角色看就清楚了。

Kafka 侧：消息几乎不可能"被消费掉"。 Kafka 是持久化日志，消费不删除数据，保留期（比如 7 天）内随便重读。Flink 的 Kafka source 消费时不逐条 ack，只在 checkpoint 里记录各分区的 offset。所以消息丢失只有两种可能：保留期过了，或者 Kafka 集群自己故障。

Flink 侧：重启 = 状态回滚 + offset 回拨，两件事同步发生。 故障后从最近一次成功的 checkpoint 恢复，同一时刻两个动作：

flowchart LR
    A["故障发生<br/>部分事件已消费已计算"] --> B["从最近 checkpoint 恢复"]
    B --> C["Kafka offset 回拨<br/>到快照时刻"]
    B --> D["算子状态回滚<br/>到快照时刻"]
    C --> E["快照之后的事件重新消费"]
    D --> E
    E --> F["在回滚后的状态上重算<br/>内部不多算也不少算"]

假设 checkpoint 间隔 60 秒：故障意味着最多重放最近 60 秒的事件——重放不是丢失，是进度倒退后追赶。由于状态和 offset 同步回滚，窗口计数这类状态计算在内部是精确的（exactly-once）。

但"对外不重复"取决于 sink，这是最容易踩的边界：

sink 类型	端到端语义	例子
两阶段提交 sink	exactly-once	Kafka sink（事务）、Iceberg
幂等写入	等效 exactly-once	Redis 按 key 覆盖写、MySQL upsert
普通追加	at-least-once，会重复	直接 insert 进 MySQL、对外发 HTTP 回调

重放的那 60 秒里，如果 sink 是普通 insert，下游表里就会出现重复行——作业内部算得再精确，写出去的那一刻语义就降级了。这就是"exactly-once 只在链路两端都配合时才成立"的含义。

真正会丢、会重的边界情况清单：

没开 checkpoint：offset 只能周期性提交到 Kafka，重启从提交点读——退化成 at-least-once，且恢复语义模糊；
Kafka 保留期 < 故障停机时间：作业停 8 天、Kafka 只留 7 天，恢复时最早的数据真没了；
异步 IO 和侧输出不参与 checkpoint：算子里偷偷调外部接口、写侧输出流，这些动作不在快照里，重放时会重复执行；
savepoint 与升级不兼容：改了状态结构（比如给状态类加了字段）还想从旧 savepoint 恢复，直接恢复失败——升级前想清楚状态兼容性。

多节点会不会重复消费同一个分区：消费组的互斥语义

顺带的另一个常见疑问：Flink 作业有几十个 source subtask 在多个节点上跑，会不会两个节点同时读同一个 Kafka 分区、把数据算两遍？

不会，这是 Kafka 消费组协议内建的互斥保证，不需要你做任何事：

同一作业的所有 source subtask 用同一个 group.id 注册，Kafka 的组协调器把分区互斥分配——每个分区同一时刻只属于组内一个消费者。200 个分区、64 个 subtask，每个 subtask 分 3-4 个，互不重叠；
节点挂了触发 rebalance，分区重新分配，但交接是排他的：旧持有者被踢出组之后，新持有者才接手，不存在两个节点同时持有同一分区的窗口；
所以同一作业内"重复消费"只有一种情况：故障恢复时的时间维度重放（上一节讲的回滚），不存在"空间维度"的并行重复。

两个相关的配置纪律：

source 并行度不要超过分区数。并行度 64、分区只有 32 个时，32 个 subtask 永远分不到分区、空转白占资源。反过来分区数多于并行度没问题，一个 subtask 可以吃多个分区。
不同作业必须用不同的 group.id。消费组之间是广播语义——画像作业和热榜作业各自完整消费同一个 topic，互不干扰，这是特性。但两个本该独立的作业如果误配成同一个 group.id，就会瓜分分区、各自只读到一半数据，这种 bug 症状隐蔽（数据看着都在流，就是量不对），值得配进上线检查清单。

数据源不止 Kafka：还能从哪读，API 数据怎么办

Flink 的 source 生态按类别列全：

类别	连接器	场景
消息队列	Kafka、Pulsar、Kinesis、RocketMQ（社区）	实时事件流的主力入口
数据库 CDC	MySQL CDC、PostgreSQL CDC、MongoDB CDC（Flink CDC 项目）	直接订阅 binlog，数据库变更实时变成流——替代"定时全量导库"，是这几年增量最大的方向
文件/对象存储	FileSource（S3 / HDFS / 本地），支持批读和持续监听目录	批处理、日志文件实时采集
JDBC	Table API 的 JDBC connector	轮询式读关系库，伪实时
测试	DataGen 数据生成器、socket 流	本地开发与压测

HTTP API 提供的数据怎么办？ 核心发行版里没有内置的 HTTP source，分两种情况：

情况一：API 是数据源（想持续消费一个 REST 接口）。正确姿势不是让 Flink 直接轮询 API，而是中间加一层 Kafka：一个轻量采集服务定时调 API、把结果写进 Kafka，Flink 消费 Kafka。原因正是前两节的内容——Kafka 提供可回放、削峰、多消费者，API 直连则什么都没有：Flink 作业一挂，这段时间的 API 数据就永远丢了。非要直连也行：实现自定义 Source 接口自己轮询，但 offset 管理、故障恢复语义全得自己做，一般不值。

情况二：API 是维表（事件流经过时补充字段）。这是更常见的需求：每条事件只有 video_id，需要调内容服务拿标题、类目、时长。Flink 有标准件——异步 IO（Async I/O）：在算子里并发调用 HTTP 接口、回调组装结果，不阻塞主流；Table API 里对应的写法是 lookup join。配一层本地缓存（Guava/Caffeine）挡掉热点 key 的重复调用，避免把对方服务打挂。注意它的语义是"查询"不是"消费"——只在事件流经过时被动调用，永远不会主动拉数据。

Spark 避坑指南

按踩坑频率排序：

数据倾斜是第一杀手。某个 key 的数据量特别大（比如头部视频占了 10% 播放量），groupBy/join 时对应分区要处理别人几十倍的数据，99% 的任务十分钟跑完，最后 1% 卡两小时。解法：给热点 key 加盐（key 后面拼随机后缀打散）、先聚合再关联、小表广播（broadcast join）避免 shuffle。
小文件问题。ETL 作业输出几万个几 KB 的小文件，下游读取慢、元数据服务被打爆。解法：写出前 coalesce/repartition 控制分区数，或开自适应合并。
shuffle 爆炸。join 两张大表，中间数据量是笛卡尔级增长。先看能不能把一张表过滤小再 join，能 broadcast 就 broadcast。
滥用 cache。.cache() 不是免费的，内存不够会挤占执行内存反而更慢。只缓存"会被复用多次"的中间结果。
分区数拍脑袋。分区太少 → 单任务处理量太大 OOM；太多 → 任务调度开销压垮 driver。经验值：单个分区处理 128MB 上下。
driver OOM。collect() 把全量数据拉回 driver——生产事故的经典配方。要看几行数据用 show()/take()。

Flink 避坑指南

状态不设 TTL 无限膨胀。keyed state 默认永不过期，跑一个月状态涨到 TB 级，checkpoint 从秒级拖到分钟级最后超时失败。用户维度状态几乎总该设 TTL（比如 7 天）。
checkpoint 间隔拍太短。间隔小于一次 checkpoint 本身的耗时，系统永远在做快照没有空算数据。先看一次 checkpoint 要多久，间隔至少留它几倍。
背压不会看。作业 lag 持续上涨，先去 UI 看背压面板：红色背压的算子就是瓶颈，瓶颈的上游全会被"传染"成红色——找到链条上第一个变红的，那才是真正的病灶。
事件时间和处理时间混用。用处理时间算"每分钟播放量"，用户手机补传的数据会把昨天的量记到今天。涉及"按发生时间统计"的需求，必须事件时间 + 水位线，并接受乱序容忍度的权衡。
扩缩容当成无状态服务做。改并行度 = savepoint + 停作业 + 重启，大状态作业分钟级中断。扩缩容策略要保守，这个坑的完整故事见 Netflix 两代 autoscaler。
exactly-once 当默认值。端到端 exactly-once 要求 sink 支持两阶段提交，代价是吞吐下降。很多监控类场景 at-least-once + 下游幂等就够了，别为不需要的语义付费。

通用坑：用 Spark 微批硬扛秒级需求。需求方说"准实时"，你拿 Structured Streaming 把触发间隔压到秒级——能跑，但状态管理和乱序处理的坑会一个个冒出来。先问清楚：延迟到底是秒级还是分钟级需求？分钟级 Spark 很舒服，秒级请直接上 Flink，别硬扛。

选型决策

数据是有界的、延迟容忍分钟级以上 → Spark
数据是持续流、延迟要求秒级、或需要复杂状态/事件时间 → Flink

但必须诚实：边界在模糊化。Spark 能做流、Flink 能做批，两个社区都在往对方的领地走；Flink 的 Table API 写 SQL 也越来越像 Spark SQL。真实的选型经常是这样决定的：团队现有栈是什么、招聘市场上谁会、云厂商托管服务谁更便宜。技术血统决定的是"哪个更顺"，不是"哪个能做"。

国内的实际格局（2020 年代中期的现状，供校准）：

新上实时项目基本是 Flink。阿里 2019 年收购 Flink 母公司后全力主推（内部版 Blink 撑双 11 实时大屏），字节、美团、腾讯、快手的实时平台全部 Flink 化，新立项用 Spark Streaming 的已很难见到；
存量离线仍是 Spark 的天下：数仓 ETL、T+1 报表、Hive 承接，生态太厚，替换动力不足；
两边都在被挤压：Spark 的机器学习场景在流失到 Python 原生生态（PyTorch/Ray）；Flink 在进攻离线——“流批一体”（一套 SQL 跑流也跑批）配合 Paimon 这类流式湖格式在落地，但离线存量太重，替换以年计；
一句话：新实时 = Flink，存量离线 = Spark，交界处（实时数仓）在打架。求职市场同构：实时岗位 Flink 是硬通货，离线岗位 Spark/Hive 是基础盘。

一句话收拢：Spark 回答"这批数据算出来是什么"，Flink 回答"这件事现在发生了什么"；先想清楚你的问题是哪一种，再选工具——反过来拿着工具定义问题，是大数据平台翻车的最常见起点。

参考：Apache Spark 与 Apache Flink 官方文档；Structured Streaming 与 Flink DataStream 的设计文档。Netflix 场景参考其技术博客公开的数据平台架构。

千人千面 + 无限瀑布流：推荐 Feed 的完整实现架构

Fri, 02 Oct 2026 18:00:00 +0800

千人千面 + 无限瀑布流：推荐 Feed 的完整实现架构

目标读者：三类人——

后端工程师：要实现一个推荐 Feed，想知道每个组件的职责边界（看"召回/粗排/精排/重排"四章和"离线 vs 在线分工总表"）；

架构师：在做 Feed 系统选型，需要 push/pull、offset/cursor 这些关键决策的对比依据（看各节的对比表）；

前端/客户端工程师：关心无限滚动的分页协议和预取时机（看"游标分页"和"预取"两节）。

阅读前提：不需要推荐算法背景，算法部分只讲工程接口，不讲模型内部。

上一篇讲 Netflix 的 Flink 扩缩容时提过一个三层结构：离线训练、近线特征、在线排序。有读者问：**首页千人千面，是每个用户打开时都跑一遍计算吗？**答案是否定的，而完整的答案就是这篇文章的主题——把微博、X 那种"每个人看到的都不一样、而且永远拉不到头"的推荐瀑布流，从客户端一路拆到数据闭环。

先把两个需求拆开，因为它们的难点完全不同：

千人千面：难在"算"——几亿用户每人一套候选，怎么做到几十毫秒出结果；
无限瀑布流：难在"协议"——内容在不断新增、排序在不断变化，怎么保证用户连续下拉时不重复、不漏看、永远有货。

总体架构：重活在用户到来之前干完

整个系统的核心思想只有一句话：请求路径上只做轻活，所有重计算都提前发生在事件流和离线任务里。

flowchart TD
    subgraph 提前计算["提前计算（用户到来之前）"]
        A["离线层<br/>批量训练模型<br/>计算全量候选池"] --> D["在线存储<br/>画像 特征 候选集"]
        B["近线层<br/>行为事件经 Kafka<br/>Flink 实时更新画像特征"] --> D
    end
    subgraph 请求路径["请求路径（用户下拉这一刻）"]
        C["在线服务<br/>召回 排序 组装<br/>几十毫秒返回"] --> E["客户端<br/>渲染一屏"]
    end
    D --> C
    E -.->|"曝光 点击 停留事件"| B

离线层（小时/天级）：Spark 类批处理训练推荐模型，算出全量候选——比如"每个用户最可能感兴趣的一万条内容"；
近线层（秒级）：用户的每一次曝光、点击、停留、点赞都作为事件进 Kafka，流处理作业（如 Flink）实时更新用户画像和特征。你上一次刷的行为，下一刷就生效——“越刷越懂你"的体感来自这一层；
在线层（几十毫秒）：你下拉刷新这一刻，服务只做"取候选 → 排序 → 组装一页”，所有重活的结果早已躺在在线存储里。

这三层 Netflix 在 2013 年就公开过（offline/nearline/online 的经典划分），至今仍是推荐系统的主流形态。上一篇 Flink 自动扩缩容里 Netflix 的"个性化自定义作业"，干的就是近线层的活。

为什么是这个分工：Kafka、Spark、Flink 各自的角色

架构图里三个组件的角色容易被误解，值得单独说清。

Kafka 不是"记录数据"的，是事件总线。 它解决四个问题：

解耦：打点的客户端不需要知道谁在消费、有几个消费者；
削峰：曝光事件的洪峰来临时，消费端可以按自己的节奏追，消息堆在 Kafka 里不会丢；
可回放：特征算错了、逻辑改了，把昨天的事件流重新放一遍就能重算——消息队列变成时间机器；
多消费者：同一份事件流同时喂给画像更新（Flink）、数仓落盘、实时监控，各取所需互不干扰。

没有它的替代方案是客户端打点直连 Flink——Flink 一挂数据就丢。Kafka 是缓冲带加保险箱。

Spark 和 Flink 看着像，血统不同：

维度	Spark	Flink
计算血统	批处理：数据是有界数据集	流处理：逐条事件，批是特例（有界流）
流处理形态	Structured Streaming 是微批（攒一批算一次）	原生逐条处理
典型延迟	秒级到分钟级	毫秒到秒级
生态主场	数仓（Hive/Iceberg）、MLlib、Python 数据科学工具链	有状态流计算：keyed state、事件时间水位线、exactly-once

分工逻辑由此而来：

训练用 Spark，因为它是吞吐型任务：几 TB 历史数据扫几遍、小时级跑完即可，不在乎单条延迟；而且机器学习工具链都在它这边。
画像更新用 Flink，因为近线层的 KPI 是"行为发生后多久生效"：要求秒级，且要维护滚动状态（最近 N 次行为的加权向量）——逐条处理加状态管理正是 Flink 的主场。用 Spark 微批也能跑，代价是生效延迟从秒变分钟，“越刷越懂你"的体感就钝了。

要诚实补一句：边界在模糊化。Spark 能流、Flink 能批，用 Spark Streaming 做近线的公司也不少。这个分工一半是技术判断，一半是生态和组织惯性——团队的历史栈是什么，往往和"哪个理论最优"同等重要。

用户偏好怎么算出来：交互矩阵与 embedding

讲四层漏斗之前，先看"偏好"这个东西在系统里的物理形态——它决定了每层能用什么数据。

一切从一张用户-物品交互矩阵开始：行是用户，列是内容（视频、微博、商品），格子里的值是行为强度。显式反馈（评分、点赞）稀疏但明确；隐式反馈（点击、停留时长、完播、划走速度）量大但噪声多——工业界主要靠后者。

矩阵太大太稀疏（几亿用户 × 几亿内容，99.99% 是空格），没法直接用，于是有了两条经典技术路线，都是十多年前就成熟的：

矩阵分解（Matrix Factorization）：把大矩阵分解成两个小矩阵——每个用户一个向量、每个物品一个向量，维度几十到几百。用户对物品的偏好 ≈ 两个向量的点积。2006-2009 年 Netflix Prize 竞赛把它打成主流，用 ALS（交替最小二乘）在集群上批量求解。
embedding（嵌入向量）：矩阵分解的现代化身。item2vec（2016）把物品当"词”、用户行为序列当"句子"套 word2vec；双塔模型（DSSM 系）用两个神经网络分别把用户和物品映射到同一个向量空间。殊途同归：最终产物都是"每个用户一个向量、每个物品一个向量，点积或余弦相似度就是偏好分"。

这套东西直接决定了离线/在线的分工：

离线算：物品向量（内容发布后批量算一次，更新频率低）、用户长期兴趣向量（按天/小时批量更新）、物品相似度矩阵；
近线算：用户短期兴趣向量——最常见的实现是把用户最近 N 次行为对应的物品向量做加权平均（行为类型加权：完播 > 点赞 > 点击 > 秒划过；时间衰减：越久的行为权重越低）。Flink 作业消费行为事件、滚动更新这个向量，秒级生效；
在线算：只剩查表和点积——拿用户向量去向量库里找最近邻，或用画像特征给候选打分。

也就是说，“用户偏好"在请求到来前就已经被压缩成几百维的向量躺在存储里了。下面四层漏斗里所有"懂用户"的操作，本质都是在读这份预先算好的压缩包。

四层排序漏斗总览

在线服务收到一次下拉请求，要在几十毫秒内从海量内容里选出这一屏的 20 条。对全量内容逐一打分是不可能的，工程上的标准解法是漏斗：每一层用更贵的模型处理更少的候选。

flowchart TD
    A["召回<br/>万级候选<br/>多路召回： 协同过滤 向量 热门 关注"] --> B["粗排<br/>千级<br/>轻量模型快速打分"]
    B --> C["精排<br/>百级<br/>深度排序模型融合全部特征"]
    C --> D["重排 混排<br/>二十条一页<br/>多样性打散 插入广告 业务规则"]

先说清一个术语问题：这套漏斗的主力技术是深度学习排序模型，不是大语言模型（LLM）。协同过滤 2000 年代就有，矩阵分解是 2009 年 Netflix Prize 的明星，GBDT+LR 是 Facebook 2014 年的论文，Wide & Deep 是 Google 2016 年的——整个栈在十年前就完整存在。LLM 近两年开始进入推荐链路（内容理解、生成标签、甚至生成式召回），但在线排序的主力依然是经典深度模型。别把"推荐系统"和"大模型"混为一谈。

召回：离线算相似度，在线做检索

任务：从几亿内容里捞出万级候选。关键词是覆盖率——宁多勿漏，漏了的后面几层救不回来。

召回是"多路并行"的，每一路是独立的候选来源，技术路径和离线/在线分工各不相同：

第一路：协同过滤（itemCF 为主）。逻辑是"和你喜欢过的东西相似的东西”。物品两两之间的相似度由共现矩阵算出（喜欢 A 的人也多大比例喜欢 B，余弦相似度），这个矩阵全离线算，按天或按小时更新，结果存 KV：item_id → 相似物品 TopK 列表。在线时只做一件事：拿用户最近行为过的物品列表去 KV 里批量查，合并候选。在线路径上没有任何矩阵运算，全是查表。

第二路：向量召回（双塔 + ANN 检索）。物品向量离线批量算好，灌进向量索引库（Faiss、HNSW 这类近似最近邻索引，百万级向量检索只要几毫秒）；用户向量由近线层滚动更新。在线时拿用户向量在索引里查 TopK——这一步是召回里唯一称得上"在线计算"的环节，但它也只是一次索引检索，不是模型推理（双塔的用户塔也可以在线跑一次，把实时上下文特征算进去，看延迟预算）。

第三路：运营类候选。热门榜、新内容池、同城/地理围栏、关注关系产出——这些本质是离线或近线算好的榜单，在线直接读。它们的作用不是精准，而是兜底和探索：新用户没有画像（冷启动）时，热门榜就是全部；老用户的候选里也固定掺一部分，保证 Feed 有新鲜感。

多路结果合并、去重、按路配额截断，凑齐万级候选交给下一层。

粗排：夹在中间的性价比层

任务：万级 → 千级。它存在的唯一理由是精排太贵——精排模型打一万条候选，延迟和算力都吃不消，但召回结果直接用又太糙。

粗排的模型选型讲究"够用就好"：早年用 LR（逻辑回归）或 GBDT，特征只取最强的一批（物品热度、用户类目偏好分、历史 CTR）；近年常用简化版双塔——向量点积打分，几乎就是向量召回的打分器复用。特征从特征存储里批量读，模型在线跑，但都是毫秒级的小模型。

工程上粗排是可选层：候选量小的业务（百万级内容池）召回直送精排也扛得住；亿级内容池才必须用它护住精排的延迟。

精排：深度学习，但不是大模型

任务：对千级候选逐条打分，预测"这个用户看到这条内容，会不会点、会看多久"。这是"千人千面"真正被算出来的地方，也是算法团队的主战场。

模型演进的主线清晰可见，每一步都发表在十年内：

年代	模型	解决的问题
2010 前后	LR	基线：特征加权和，可解释、可工程化
2012	FM / FFM	自动学习特征两两交叉（“男性 × 游戏类"这种组合特征不用人工配）
2014	GBDT + LR（Facebook）	GBDT 自动做特征组合和离散化，输出喂给 LR
2016	Wide & Deep（Google）	Wide 侧记忆规则（“已安装的应用”），Deep 侧泛化（embedding 学没见过组合）
2017-2018	DeepFM / DIN（阿里）	DeepFM 把 FM 嵌进网络；DIN 引入注意力——给用户历史行为按"和当前候选的相关性"加权，你刷运动鞋时，你上周看鞋的权重就压过看手机的

注意这张表里没有一个是大语言模型。它们参数量百万到亿级，输入是结构化特征向量，一次推理是几十毫秒的批量矩阵乘法。

精排的在线链路是漏斗里最长的：

flowchart LR
    A["候选列表 千级"] --> B["特征拼接<br/>用户画像 物品特征<br/>实时上下文: 时间 设备 网络"]
    B --> C["特征存储 Feature Store<br/>离线特征读 KV<br/>近线特征读 Flink 产出"]
    C --> D["深度排序模型<br/>批量推理 输出 CTR/时长预测"]
    D --> E["按预估分排序<br/>截断到百级"]

关键组件是特征存储（Feature Store）：离线特征（用户长期画像、物品属性）和近线特征（最近一小时的点击序列、实时曝光计数）在请求时按 key 批量读出、和实时上下文（现在是几点、什么设备）拼成特征向量。特征的一致性是这个环节最大的坑：离线训练用的特征和在线服务用的特征必须同一份定义，否则"训练时很准、上线后翻车”——特征平台存在的意义就是管这份一致性。

重排/混排：从"预测喜欢"到"设计一页"

精排输出的是分数，但分数最高的 20 条直接端给用户往往体验很差：可能十条都是同一个作者、同一类题材。重排层的职责变了——不再预测"你多喜欢"，而是设计"这一页长什么样"。它几乎全是规则和策略，在线执行：

多样性打散：相邻 N 条不允许同作者/同类目；更讲究的用 MMR（每次选"分高且与已选差异大"的）或 DPP（行列式点过程，数学上保证选出的集合整体多样）；
混排：把广告、关注更新、运营位按规则插进自然结果。广告有自己的排序逻辑——eCPM = 出价 × 预估点击率，既要用户可能点、又要广告主出价高；
负反馈过滤：你点过"不感兴趣"的作者和类目，在这里被硬性屏蔽；
业务护栏：去重、过滤已举报/审核中内容、新内容冷启扶持配额。

重排是业务规则密度最高的一层，通常做成规则引擎而不是模型——产品运营每周调的都是这里。

离线 vs 在线：一张分工总表

把全链路摊开，每个环节算什么、什么时候算、存哪里，一张表收拢：

环节	算什么	离线/近线/在线	存储
模型训练	排序模型参数、双塔参数	离线（小时/天）	模型仓库
物品向量	内容的 embedding	离线（发布时 + 定期刷新）	向量索引库（Faiss/HNSW）
物品相似度	itemCF 共现矩阵	离线（天/小时）	KV
热门榜/新内容池	全站榜单	近线（分钟级滚动窗口）	KV
用户长期画像	长期兴趣向量、类目偏好	离线（天）	KV / 特征存储
用户短期兴趣	最近行为的加权向量	近线（秒级，Flink）	特征存储
召回	查相似物品、ANN 检索、读榜单	在线（但全是查表/检索）	—
粗排/精排	特征拼接 + 模型打分	在线（特征预先备好，只做推理）	—
重排/混排	规则执行	在线	—
已曝光记录	用户看过什么	在线读写，近线聚合	KV / 布隆过滤器

规律一目了然：越靠近"知识沉淀"（模型参数、向量、相似度）的越离线，越靠近"当下上下文"（你刚点了什么、现在几点）的越在线。在线路径上真正的计算只有两样——向量检索和模型推理，其余全是查表。

注意一个工程事实：漏斗每一层都是"算法团队调模型、工程团队保接口"。接口契约是稳定的（输入候选列表和特征，输出打分排序后的列表），模型怎么迭代都不影响上下游——这是推荐系统能持续进化的架构前提。

无限瀑布流（一）：分页协议为什么必须是游标

无限下拉遇到的第一个坑是分页。直觉做法是 offset 分页（“给我第 41-60 条”），在推荐流场景下它有三个致命伤：

问题	offset 分页	cursor 游标分页
新内容插入头部	第 2 页和第 1 页之间内容错位，用户看到重复	游标锚定"上次最后一条"，新内容插进来也不影响
排序实时变化	每次请求重新排序，offset 语义直接失效	游标携带上次的排序上下文
深翻页性能	数据库 OFFSET 越大越慢	从锚点继续，代价恒定

所以推荐流的分页协议长这样：每次请求带一个游标（cursor），响应返回一页内容 + 下一页的游标。

请求:  GET /feed?cursor=eyJscCI6...&count=20
响应:  { "items": [...20条...], "next_cursor": "eyJs..." }

游标是个不透明字符串（服务端编码，客户端不许解析），里面通常装着：上一页最后一条的标识和排序分、本次推荐的批次号、过期时间。“不透明"是关键设计：服务端可以随时改游标格式和分页逻辑，客户端零感知。

无限瀑布流（二）：一次下拉请求的完整链路

把上面两节合起来，用户下拉一次的完整链路：

sequenceDiagram
    participant U as 客户端
    participant F as Feed 服务
    participant S as 在线存储
    participant R as 排序服务
    U->>F: 下拉 带上次游标
    F->>S: 查用户画像和已曝光记录
    F->>S: 取候选集 多路召回合并
    F->>R: 粗排 精排 重排
    R-->>F: 排序后的候选
    F->>F: 过滤已曝光 取一页<br/>写入已曝光记录
    F-->>U: 返回 20 条 + 下一页游标
    U->>U: 渲染 上报曝光事件

链路里有两个不那么显眼但缺一不可的组件：

已曝光去重（seen filter）。用户刷过的内容不能再出现，否则无限下拉就成了无限重播。实现上是在线存储里维护每用户的已曝光集合——请求时过滤、响应后写入。数据量大时用布隆过滤器压缩内存（允许极低误判率，误判的代价不过是少推一条内容），或者按天滚动窗口只记最近 N 天的曝光。

预取（prefetch）。如果等用户滑到底再发请求，每一页都有加载等待，无限流就成了"有停顿流”。客户端的标准做法：滚动到当前列表 70%-80% 位置时就预取下一页；网络差时加大预取提前量。用户感知到的"永远流畅"，一半是服务端架构，一半是这一个提前量。

“永远拉不到头"怎么兑现

这是无限瀑布流真正的核心问题：个性化候选再多也是有限的，用户刷 200 屏之后呢？答案是分层供给，逐级降级：

个性化候选：精排得分最高的一批，前几十屏的主力；
探索流量（exploration）：故意混入你没表现出过兴趣的类目——推荐系统必须留探索比例，否则画像会收敛到死胡同（信息茧房在工程上的成因就是探索为零）。这层对用户是"刷到了意外之喜”，对系统是"采集新兴趣信号"；
热门与新内容兜底：当个性化候选耗尽，降级到全站热门、最新发布——这些内容池每天都在被离线任务刷新，事实上是无限的；
时间衰减：同一条内容的推荐价值随时间衰减，昨天刷过的爆款明天权重下降，保证"明天再来还有新东西"。

所以"永远拉不到头"不是因为算出了无限多的个性化结果，而是因为个性化耗尽之前，系统会不露痕迹地滑向兜底池。用户刷到第 100 屏时看到的"千人千面"，成分里热门内容的占比早已悄悄超过个性化——体验连续，供给无限。

数据闭环：这一刷决定下一刷

最后把环闭上。客户端上报的每一条曝光、点击、停留时长、划走速度，都经 Kafka 进入近线层：

停留 5 秒以上 → 画像里对应类目的权重上调；
秒划走 → 权重下调；
点了的广告、取关的话题 → 写入负反馈特征。

下一刷的召回和排序用的就是更新后的画像。推荐系统的"智能"不在某一次排序多准，而在于这个闭环转得多快——从行为发生到画像生效的延迟，直接决定用户"它懂我"的体感。这也是为什么 Netflix 那样的公司要养三万个流处理作业、还专门给它们做自动扩缩容。

和关注流的关系

顺带澄清一个常见混淆：微博、X 都有两种流——

关注流（关注的人发的内容，按时间排序）：经典问题是写扩散（发微博时推给所有粉丝）还是读扩散（刷的时候现拉），粉丝量大的大 V 是写扩散的噩梦；
推荐流（本文讨论的）：没有"关注"这个约束，内容来自全站，靠排序漏斗筛选，游标分页。

现代产品里两者早已混合：推荐流里插关注内容、关注流里插推荐内容，都在重排混排那一层完成。

落地清单

如果要自己实现一套，按这个顺序检查：

骨架

三层分离：离线训练、近线特征、在线排序，请求路径上只留轻活；
排序漏斗四层：召回保覆盖、粗排保性价比、精排保准确、重排保体验，层间接口契约稳定。

无限流协议

游标分页，游标不透明、带过期时间；
已曝光去重：在线集合或布隆过滤器，按天滚动窗口；
客户端 70%-80% 位置预取下一页。

“拉不完"的保障

分层供给：个性化 → 探索 → 热门/新内容兜底，降级要无感；
探索流量比例显式配置，别让它收敛到零；
内容时间衰减，保证"明天还有新东西”。

闭环

曝光/点击/停留全量上报，经消息队列进近线层；
监控"行为 → 画像生效"的端到端延迟，这个数就是用户体感的下限。

一句话收拢：千人千面不是"为每个用户算一遍"，而是把计算摊到用户到来之前的每一秒里；无限瀑布流不是"有无限内容"，而是个性化耗尽之前，系统早已悄悄换档。两个魔术的机关，都在用户看不见的那一侧。

想直观感受这套漏斗里的数据长什么样，可以看姊妹篇《从余弦定理到 TikTok：一个用户的推荐流是怎么被算出来的》——造一个用户，带着他一晚上的行为数据走完召回、粗排、精排、重排。

参考：Netflix 技术博客的个性化系统架构（offline/nearline/online 三层划分）；推荐系统排序漏斗与游标分页为业界通用架构实践。

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

Fri, 02 Oct 2026 17:00:00 +0800

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

目标读者：三类人——

平台/数据工程师：正在或准备给 Flink 作业做自动扩缩容，想知道选哪个方案、坑在哪（看"背景二"和"三个工程缺口"）；

架构师：在给实时计算平台做选型，需要"外部指标 vs 内部推理"两条路线的完整对比（看两代方案的对比表）；

CTO/技术管理者：关心自研和开源的边界，Netflix 从自建收敛到开源的过程是一个现成的决策样本（看"三条可以带走的教训"）。

没跑过 Flink 也能读：正文前两节是背景知识；跑过的可以直接跳到"第一代"开始看。

之前那篇《软件知识的分层与获取地图》说过：方案层的知识没有教材，只有案例，大厂技术博客是主力来源。最近去读了 Netflix 技术博客的 A Tale of Two Flink Autoscalers，讲的是他们怎么做流处理作业的自动扩缩容。这篇是我的学习笔记，把里面的架构知识点整理出来。

问题的形状很普遍：作业负载随昼夜、活动、故障转移大幅波动，按峰值配资源浪费，按均值配资源高峰期 lag 爆炸。Netflix 的答案是先后造了两代 autoscaler，现在正在从自研收敛到开源。两代的设计差异和迁移教训，比算法本身更有价值。

不过进入正题前，先补两段背景：Flink 是什么、扩缩容在这上面为什么天然就贵；以及开源社区现在有哪些现成方案、谁更好。

背景一：Flink 是什么，扩缩容为什么贵

Apache Flink 是开源的流处理框架，核心能力是"对无界数据流做有状态计算"：数据像水管里的水一样源源不断地来（Kafka 消息、日志、点击流），Flink 一边流一边算，算出实时结果（实时报表、实时推荐、风控告警）。

一个 Flink 作业（job）在逻辑上是一张算子组成的有向无环图（DAG）：数据从 source 进来，经过 map、keyBy、window、join 这些算子的处理，最后写到 sink。

flowchart LR
    A["source<br/>读 Kafka"] --> B["map / filter<br/>转换清洗"]
    B --> C["keyBy + window<br/>分组聚合 带状态"]
    C --> D["sink<br/>写下游"]

要理解扩缩容为什么难，需要知道四个机制：

并行度（parallelism）：每个算子可以拆成多个并行实例（叫 subtask），分摊在集群的 TaskManager 进程里跑。所谓"扩缩容"，本质就是调整各算子的并行度、增减 TaskManager。
状态（state）：keyBy 之后的窗口、聚合结果都存在状态里，大作业的状态可以到 TB 级。状态按 key 分布在各个并行实例上。
checkpoint / savepoint：Flink 定期把状态整体快照下来，用于故障恢复。改并行度意味着状态要在新数量的实例间重新分配——所以扩缩容的标准动作是"做 savepoint → 停作业 → 按新并行度重启 → 重新加载状态"，状态越大恢复越慢。
背压（backpressure）：下游算子处理不过来，会沿着数据流反向"顶住"上游。背压是判断"瓶颈在哪个算子"的关键信号，也是第二代 autoscaler 的数据基础。

一句话：无状态服务扩缩容是加台机器的事；有状态流处理扩缩容是一次"带着全部家当搬家"。这就是为什么"自动扩缩容"在无状态微服务上早就普及，在 Flink 上却直到这两年才有成熟方案。

背景二：开源社区有什么方案，谁更好

给流处理作业做自动扩缩容，社区里前后出现过几条路线：

方案	原理	粒度	现状
Flink Reactive Mode（1.13 起）	作业自适应集群里现有的 TaskManager 数量，配合 K8s HPA 按 CPU 伸缩容器	整个作业一刀切	简单可用，但按容器指标决策，看不见作业内部瓶颈
Apache Flink Autoscaler（Flink Kubernetes Operator 内置）	从作业内部逐算子算"真实处理速率"，按需逐顶点调并行度	逐算子	社区主力方向，本文的主角
云厂商托管服务（如 AWS Managed Service for Apache Flink）	平台按容器利用率自动伸缩	整个作业一刀切	零运维但粒度粗，复杂有状态作业效果有限
各家自研（Netflix 第一代、当年 Twitter Heron 的 Dhalion 等）	外部指标（CPU、lag、背压）+ 自研策略	整个作业一刀切	大多是"社区没有成熟方案时"的历史产物

谁更好？对 2026 年刚开始做这件事的团队，答案基本收敛了：

作业跑在 K8s 上 → 直接用 Flink Kubernetes Operator 自带的 autoscaler，顶点级、背压感知，是当前最通用的最优解；
平台是自建的（不在 K8s 上、有自己的控制面）→ 核心算法库已经独立出来，可以像 Netflix 一样只接四个接口（下文详述），不必自建；
作业简单、无状态、量不大 → Reactive Mode 或云托管的粗粒度伸缩就够用，别上重武器；
从零自研外部指标 autoscaler → 2019 年的合理选择，2026 年不太成立——Netflix 自己正在从这条路迁走，这就是用脚投票。

有了这个背景，Netflix 这两代方案的故事就好读了：它几乎把上面每条路线都趟了一遍。

为什么这个问题在 Netflix 躲不掉

先看规模：2026 年，Netflix 在多个 AWS 区域跑着 3 万多个 Flink 作业（2017 年开始用 Flink）。这决定了"人肉运维"这条路根本不存在。

这三万个作业到底在干什么业务？按原文的分类可以拆成两大块：

大头是托管平台 Data Mesh 自动生成的数据管道——所以这三万个作业的主体确实是"大数据相关"，不是在跑在线业务服务。Data Mesh 是 Netflix 的托管数据搬运/处理平台（2023 年他们在博客公开过架构）：用户在界面上声明"数据从哪来、到哪去、中间做什么转换"，平台自动生成 Flink 作业——典型场景是 Kafka 之间的数据搬运、数据库变更（CDC）实时同步到数仓（Iceberg）、事件路由分发。用户大多根本不直接接触 Flink，自然也不会去管扩缩容。
少数但增长快的是各团队自建自运维的自定义作业，承载真正的实时业务逻辑：个性化（实时推荐特征计算）、广告（2022 年广告套餐上线后的曝光与计费遥测）、直播活动（体育赛事直播的实时监控）等。原文里靠 autoscaler 省下 110 万美元的案例，就来自做客户端遥测和日志的团队。

形态差异也很大：从 Kafka 搬运工式的单算子作业，到带分支、join、TB 级状态的复杂流水线都有——记住这个差异，后面两代 autoscaler 的能力边界正好卡在这里。

顺带澄清一个容易误解的点：首页千人千面的推荐，不是每个用户打开时都走一遍 Flink。Flink 是流处理引擎，干的是"事件来了就算"，不在用户请求链路上。个性化系统是经典的三层结构（Netflix 早在 2013 年就公开过这套架构）：

flowchart LR
    A["离线 offline<br/>批量训练模型<br/>计算全量候选集"] --> D["在线存储<br/>画像 特征 候选集"]
    B["近线 nearline<br/>行为事件进 Kafka<br/>Flink 实时更新画像特征"] --> D
    D --> C["在线 online<br/>打开首页时排序组装<br/>几十毫秒返回"]

你在观看、暂停、评分时产生的行为事件，由近线层的 Flink 作业实时消化、更新画像；你打开首页那一瞬间，在线服务只做"查 + 排"，几十毫秒返回。把重计算从请求路径挪到事件流上，正是个性化系统扛住全球用户规模的关键设计——本文说的"个性化"自定义作业，干的就是近线这一层的活。

更麻烦的是约束条件：在这个平台上，扩缩容不是免费的。默认动作是"做 savepoint → 优雅停掉作业 → 按新规模重启"，大状态作业一次要几分钟。这意味着扩缩容策略不能冲动——每次动作都是分钟级的中断。

于是一个真正难的问题摆在面前：如何在没有人的情况下，让每个作业在需要时拿到需要的资源，同时不把任何东西搞挂？

第一代：从外面看的 autoscaler（2019）

Netflix 的第一个答案本身就是一条流处理作业：跑在自家 Mantis 平台上，消费遥测系统 Atlas 吐出的集群级实时指标——每个作业的 CPU、网络、Kafka lag、摄入速率、消费速率。

决策逻辑是几种信号的组合：lag 推导出的追赶时间、CPU/网络利用率阈值、历史性能基线、对近期摄入速率做回归预测，然后决定扩容，或者判断"更小的集群也扛得住未来窗口"从而缩容。

这个设计有两个当时看来很聪明、事后定义了天花板的选择：

它独立于 Flink 平台运行。Flink 自己出问题时扩缩容不受牵连；而且按"流处理作业"的形态来构建，天然好扩展——每个 autoscaler 节点负责一部分 Flink 作业的指标，从没写过什么分片协调逻辑。
成绩单不差：在几千个托管流水线上稳定砍下 25%-45% 的资源用量（Flink Forward 2020 分享过）。

但"从外面看"是有代价的，原文叫它 ceiling（天花板）：

粗粒度 + 单一旋钮。它通过容器级指标推理整个集群，而且只能调一个数——TaskManager 总数，也就是作业里所有算子同比例缩放。对单算子简单流水线够用，对多算子、有状态的 DAG（广告、推荐、游戏团队越来越多拿来的正是这种）就无能为力——而这恰恰是它推理不了的作业类型。每接一种新 case 就得加定制逻辑，形不成通用能力。
指标会骗你。autoscaler 的天花板就是外部指标系统的天花板。有的作业明明忙得团团转，CPU 利用率上却毫无体现，作业卡在降级状态里，scaler 根本看不见。更狠的一次：一次网络迁移悄悄改变了部分流量的上报口径，Atlas 里 scaler 依赖的一组指标开始漏报——这个缺口在生产环境潜伏了很久才暴露。

到这一步，build vs buy 被重新摆上了桌面。

第二代：从里面推理的 autoscaler（开源方案）

2019 年自建时，Flink 社区没有成熟的 autoscaler；等 Netflix 重新评估时，已经有了：Apache Flink Autoscaler。思路发生了根本变化——不从外面看容器，从作业内部推理。

核心概念是真实处理速率（TPR, True Processing Rate）：一个算子如果满负荷运转，能扛住的吞吐是多少。

Flink 会按 subtask 上报"每秒真正干活的时间占比"（和背压时间、空闲时间分开统计）。用观测吞吐除以忙碌占比，就能把容量外推到满负荷：

一个算子实测每秒处理 700 条记录、忙碌占比 70%，TPR = 700 / 0.7 = 1000 条/秒。

有了这个数，autoscaler 从 source 开始遍历整个作业 DAG，结合每个算子的 TPR、输入输出比率和目标利用率，逐顶点计算需要的并行度——保证没有任何一个算子成为瓶颈，而不是把整个集群当整体伸缩。

flowchart TD
    A["Flink 上报<br/>每个 subtask 的忙碌占比"] --> B["TPR = 观测吞吐 / 忙碌占比<br/>外推满负荷容量"]
    B --> C["从 source 遍历作业 DAG<br/>结合输入输出比率"]
    C --> D["逐顶点计算目标并行度<br/>没有算子成为瓶颈"]

两代方案的契约差异：

维度	自研（外部观察）	开源（内部推理）
信号来源	容器级指标（Atlas）	作业内 per-vertex 指标
决策单元	整个集群一个旋钮	DAG 逐顶点并行度
适用作业	单算子简单流水线	多算子有状态 DAG
配置粒度	全局统一	每个作业可自定义

对 Netflix 来说，决定性的就是后两行：开源方案能扩缩的恰好是自研系统天生处理不了的那类作业，而且每个作业可以带自己的配置（稳定期、阈值等扩缩行为参数）——这正是那些一直被人工扩缩容的自定义作业需要的。

落到三万个作业：三个工程缺口

算法层面拿来即用，社区已经把难的部分做完了。Netflix 的工作是让它在自己的体系里可靠运转——这才是"社区能跑"和"Netflix 规模能跑"之间的距离。

接入方式：独立库 + 四个接口。 开源 autoscaler 最初架构在 Flink Kubernetes Operator 里，而 Netflix 的 Flink 平台跑在自己的控制面上。社区后来做了一个关键决策：把核心逻辑抽成独立库，只留四个通用接口——携带作业元数据和 REST 信息的 context、状态存储、事件处理器、执行扩缩动作的 realizer。Netflix 的接入服务是一个 Spring Boot 应用，编排跑在 Temporal（持久化工作流引擎）上：一个编排工作流每分钟轮询一次控制面，为每个开启扩缩容的作业启动一个独立的长运行工作流。

flowchart LR
    A["Temporal 编排工作流<br/>每分钟轮询控制面"] --> B["每个作业一个<br/>独立长运行工作流"]
    B --> C["从 JobManager 拉<br/>per-vertex 指标"]
    C --> D["跑开源评估算法"]
    D --> E["realizer 通过控制面<br/>执行扩缩"]

“每个作业一个工作流"是直接被 pain 教育出来的设计：最初用单一批处理循环评估所有作业，一个慢作业或异常作业能卡住它后面所有作业的指标采集和扩缩。拆开之后，单个作业出问题只在自己的工作流里失败重试，爆炸半径被隔离，接入更多作业时运行时水平扩展即可。

三个必须自己补的工程缺口：

高并行度下的指标采集。大作业上从 JobManager 拉指标成为瓶颈，部分原因在 Flink 运行时本身。Netflix 改了 JobManager：缓存瞬时指标名、统一清理而不是每次拉取都重扫，并加了服务端过滤让 autoscaler 只拉需要的指标。效果：可用规模从约 1000 个 subtask 提到 3000 个。这些改动在内部 fork 里，部分已贡献回上游（如 FLINK-36172）。
保住 forward chaining。由 forward 边连接的两个顶点必须同并行度——记录是在内存里走固定本地通道交接的。如果只扩一个，Flink 不会报错，它会悄悄把这条边转成网络 shuffle（性能完全另一回事）。Netflix 的 fork 会检测 forward 连接的子图，把它们当整体扩缩。
尊重 sink 的容量上限。有些 sink 写入能力有限，把上游作业扩上去只会把自己顶死。fork 里加了 async-sink 背压检测，阻止 autoscaler 把作业扩到 sink 吃不下。

最后还有 realizer 的安全检查：比如公司级区域故障转移期间，拒绝在被撤离的区域缩容；执行前确认新集群磁盘放得下作业的 checkpoint 状态；大集群再加一点 standby 缓冲。

效果与调校

开源方案的 autoscaler 去年在 Netflix 自定义作业上 GA，早期结果里有个硬数字：客户端遥测日志团队的 Flink 计算支出年化下降 58%，约省 110 万美元。效率来自三件事：

静态配置永远要按峰值留量，autoscaler 吃掉了昼夜和周末低谷；
性能优化或节后流量回落之后，不再依赖团队手工降配，autoscaler 持续跟进；
统一容器规格带来更好的装箱（bin-packing）和更细的扩缩粒度。

但"缩得太狠"是另一个坑：砍过头 CPU 打满、lag 飙升，而系统没法立刻反应——每次重启后指标窗口和稳定期都要重建。Netflix 现在把目标利用率定在 0.45，低于社区默认的 0.7，故意用一点效率换稳定：对大型有状态作业，更少、更平稳的扩缩动作值这个价。

剩下的最大成本已经不是 scaler 的逻辑，而是重启和状态恢复本身。Flink 2 的分离式状态架构（状态放外部存储而不是本地磁盘）有望让扩缩代价与状态大小解耦——Netflix 已开始支持 Flink 2.2，准备实验新 state backend。

三条可以带走的教训

文章结尾总结的三条，泛化到 Flink 之外依然成立：

指标选择比算法精巧更重要。 最有价值的调试很少是关于扩缩数学的，而是"该信哪个信号”。调算法之前，先搞懂你的指标——口径会变、会漏报、会测不到真正的瓶颈（第一代 scaler 的两次事故都是指标层的）。
默认值要合理，但留出调节空间。 托管作业相似度够高，一套好默认值覆盖大多数——这正是平台的意义。但把单一配置强加给所有作业，是在惩罚不适配的那些：默认值 + 每作业覆盖，同时把需要深专业知识的旋钮藏起来。大多数团队永远不该需要思考 autoscaler 的存在。
先采用，再扩展（Adopt, then extend）。 2019 年自建是因为没有成熟选项；社区方案出现后，正确的动作既不是永远捍卫自己的投资，也不是连夜拆掉，而是：新工作负载先用开源的，把修复贡献回上游，再有计划地迁移存量。自研基础设施的真实成本，要在"本来可以采用现成方案"的对照下衡量。

一句话收拢：自动扩缩容的难点从来不在"扩缩"二字，而在于你凭什么相信指标、怎么隔离故障、以及什么时候承认社区已经做得比你好了。

来源：Samuel Yeboah, Francesco Di Chiara, Mingliang Liu, “A Tale of Two Flink Autoscalers”, Netflix TechBlog。

Netflix 服务拓扑系统笔记：实时依赖地图是怎么被生产环境捶出来的

Mon, 13 Jul 2026 10:00:00 +0800

Netflix 服务拓扑系统笔记：实时依赖地图是怎么被生产环境捶出来的

原文：Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned 目标读者：做过或准备做流式数据管线的后端工程师；被 Kafka 消费滞后、JVM GC、热点节点折磨过的人读起来会格外有体感。阅读目标：搞清楚这套系统的三个核心决策（流式优先、三级聚合管线、动态一致性哈希）各自解决了什么问题，以及 V1 到 V2 连环踩坑的顺序——那个顺序比任何单个方案都值得记住。

〇、开场白比正文值钱

这个系列第一篇讲的是 what 和 why：Netflix 工程师需要统一的实时服务依赖视图来加速排障、评估爆炸半径，方案是把 eBPF 网络流、IPC 指标、分布式追踪三个数据源做成物理隔离的三层图。这篇讲的是 how——工程现实。

作者的开场自白很诚实：V1 在本地环境完美运行，上生产就是另一个故事。Kafka 消费者落后，实例内存耗尽，有的节点流量是其他节点的 100 倍，GC 停顿吃掉的 CPU 比业务逻辑还多。这篇文章不是成功故事，是一趟踩坑复盘。

一、流式优先：新鲜度不是锦上添花

传统拓扑系统是批处理：按小时或按天聚合，存全量快照。小规模没问题，但凌晨三点出事故时，一小时前的依赖图是考古，不是可观测性。

决策是 streaming-first：多区域 Kafka 流和 IPC 指标以 Server-Sent Events 持续摄入，反应式管线处理，拓扑更新延迟在几十分钟量级，对比批处理的小时级、天级。事故响应、变更验证这些场景等不了下一个小时级批次。

流式处理绕不开一个根本问题：下游慢了怎么办？三个传统方案都不行——无界队列会缓冲到内存爆掉；丢弃式流控会让拓扑残缺，丢的正是连接信息；批处理来不及。他们的答案是背压：Stage 3 写图数据库写不动，通知 Stage 2 减速，Stage 2 通知 Stage 1，Stage 1 让 Kafka consumer 暂停拉取，数据就在 Kafka 里等着。任何一级被打爆（流量尖峰、GC 停顿、外部系统变慢），整条管线自动降到可持续的速率。数据晚到几秒几分钟，但既不丢也不崩。代价是反应式流本身的复杂度，这个后面会还回来。

二、三层物理隔离

多源方案落地为三个物理隔离的层，各自配不同的存储：

网络层：eBPF 流日志，存图数据库分区。覆盖全，但没有应用上下文。
IPC 层：应用指标，存另一个与网络层隔离的图数据库。端点信息丰富，但只覆盖插桩了的服务。
追踪层：分布式追踪，存列式存储（Parquet）。是真实请求路径，但有采样。

物理隔离的意义是各层可以按自己的吞吐、查询模式和演进节奏独立优化。查询时并行查相关存储再合并结果，做到亚秒延迟。

三、三级聚合管线：一个架构解两个题

这是全文的核心。网络流日志有个根本缺陷：它只能看到单个网络跳，看不到应用级连接。云环境里流量很少直连，中间隔着负载均衡器、NAT 网关、API 网关、代理。流日志里 App A 到 LB 是一条流，LB 到 App B 是另一条流，但工程师要的是 App A 到 App B 这条逻辑依赖。

flowchart LR
    K["多区域 Kafka<br/>eBPF 流日志"] --> S1["Stage 1 初始聚合<br/>过滤非法流<br/>5 分钟时间窗聚合<br/>一致性哈希分发"]
    S1 -->|"SSE 流"| S2["Stage 2 中间件解析<br/>按中间件分组<br/>双跳拼成直连边<br/>再次一致性哈希"]
    S2 -->|"SSE 流"| S3["Stage 3 最终聚合与富化<br/>查 KV 补元数据<br/>转成图实体<br/>限流写库"]
    S3 --> DB["图数据库"]
    S3 -.->|"背压: 写不动就减速"| S2
    S2 -.->|"背压传播"| S1
    S1 -.->|"暂停拉取<br/>数据留在 Kafka"| K
    style S2 fill:#fff3cd

三个要点：

为什么三级而不是一级？数据局部性。 要把 App A 到 LB 加 LB 到 App B 拼成 App A 到 App B，必须让同一个中间件的所有流落在同一台实例上做 join。而 Stage 1 里流是按 Kafka 分区散在各实例上的。所以 Stage 2 的关键职能是按中间件标识重新分发——经典 map-reduce：Stage 1 做 map，Stage 2 做 shuffle 加 reduce，Stage 3 做最终聚合。

flowchart TD
    subgraph RAW["解析前 两条单跳流"]
        A1["App A"] --> LB["Load Balancer"]
        LB --> B1["App B"]
    end
    subgraph RES["解析后 逻辑依赖"]
        A2["App A"] -->|"合并双跳指标<br/>记录途经的中间件"| B2["App B"]
    end
    RAW ==>|"按中间件 shuffle 到同一实例<br/>join 入流与出流"| RES
    style RES fill:#e8f5e9

为什么三级而不是两级？ 他们最初就是两级，测试能跑，生产翻车：中间件解析要求把某个热门中间件的所有流集中到一台实例，热点应用的实例成了热节点；而数据富化（查外部存储拿健康状态和元数据）又意味着最忙的实例同时 I/O 最重。拆成三级后，解析（计算密集）和富化持久化（I/O 密集）隔离，每条流被分发、解析、再分发、最后持久化——负载被两轮哈希打散，即使中间件流量是平均值的 100 倍，也没有单实例成为瓶颈。

为什么 SSE 而不是 gRPC？ 最初用的 gRPC，结果序列化开销、连接池管理、流式响应的内存压力吃掉的 CPU 比业务逻辑还多。消息队列则白白增加基础设施复杂度。SSE 轻量、HTTP 基础、和反应式流的背压天然集成。教训原话：行业最佳实践不普遍适用，测量，别假设。

为什么 IPC 层一级就够？ IPC 指标本来就是应用级的，没有中间件要解析；而且数据从源头就按一致性哈希分对了。这带出一条普适原则：数据的分区方式决定处理架构——进来时分对了就直接聚合，分不对（比如网络流需要中间件解析）就得加 shuffle 级。

四、动态一致性哈希：白嫖现有基础设施

ASG 动态扩缩容时怎么决定哪个实例收哪个 aggregator？传统做法假设静态集群，扩缩容要显式再平衡、协调服务或手工搬数据。他们的做法：每个实例查服务注册中心拿当前健康的实例列表，排序（保证所有实例视图一致），然后用 findOwnerInstance(aggregator.primaryKey) 路由。注册中心本来就为健康检查跟踪着 ASG 成员，拿它当集群成员的事实来源，动态成员资格是白来的。一致性哈希保证成员变化时大部分 aggregator 留在原实例，排序列表保证视图一致。扩容时新实例立即接到自己那份流量，部署时 aggregator 无缝漂移到健康实例，全程无协调协议、无人工干预。

五、V1 的四个坑，一个连一个

坑一：Kafka 消费滞后。 lag 从秒涨到分钟再到小时。插桩后发现四个原因：分区数对消费组规模偏少、单次 fetch 拉取记录太少、socket 缓冲区没按吞吐调、跨区域读有额外延迟。对症：加分区、调大每次 fetch 的记录数（拿单条延迟换吞吐）、加大接收缓冲。结果 lag 降到峰值时也在一分钟内。然后新瓶颈暴露了：实例自己吃不下更高的摄入速率——修一个瓶颈必然暴露下一个，这是分布式系统的常态。

坑二：热点节点与数据放大。 最严重的问题。认证、推荐这类热门服务被几百个服务调用，流记录多几个数量级；最初按目的服务做一致性哈希归属，于是拥有热门服务的实例流量是别人的 100 倍。更糟的是洗牌时的数据放大：10 个实例都有本地客户端调某个服务，各自把 aggregator 发给 owner，owner 要合并 10 份。async-profiler 加 heap dump 的结论很清楚：热实例 CPU 大头在 GC，内存压力导致 GC 抖动，抖动吃 CPU，CPU 慢了内存压力更大——恶性循环直到实例宕机，负载转移引发级联故障。解法就是前面那套三级管线：Stage 1 先在内存里做 5 分钟窗口的在线聚合，原始流尽快丢弃被 GC，网络上传的只有压缩后的聚合结果；再经两轮哈希打散。为一个需求（中间件解析）做的架构决策，顺手解了另一个问题（负载不均）——作者说这叫有益的副作用。

坑三：内存与 GC。 修完热点还有高堆占用。原因有三：对象要等 5 分钟窗口攒完、数据在各级间做不必要的类型转换、以及——最有争议的一条——按 Scala 最佳实践用不可变数据结构做 aggregator，每次更新都造新对象，每秒百万记录下垃圾回收器直接被淹没。务实选择：热路径上改用可变 aggregator（别处保持不可变），堆分配降了 50% 以上，GC 停顿从几百毫秒降到几十毫秒。教训：最佳实践是起点不是戒律，要用测量来背书，并且清醒地知道自己交换了什么。

坑四：反应式流的复杂度。 Pekko Streams 管线会莫名其妙 stall，没有堆栈可查；.async 操作符一开始用错，过度并行的流开销大于收益。应对：投入时间真正学懂需求驱动模型、把流图简化为线性流优先、在流边界加监控（缓冲区大小、元素吞吐、背压事件）、团队内部沉淀文档。强力抽象需要投资，别假设自己会了。

六、V2：把能跑的打磨成生产级

V1 解决了架构级问题，V2 是持续优化，模式都一样——生产暴露假设，profiling 定位根因，定点修复：

aggregator 全程直达：之前每级之间都把 aggregator 转成完整图实体，其实下级只需要压缩状态。改为只在 Stage 3 落库前转换一次，砍掉两次中间转换。
序列化统一 JSON：自定义序列化导致难以复现的偶发错误。JSON 比二进制略低效，但人可读让调试容易得多，一致性直接消灭了一整类 bug。
流参数调优：继续调并行度、缓冲区、.async 边界位置。
图数据库写入不均：某些分区写流量大、某些闲置，限流触发不均。改为批量写入加改进分区分布逻辑。
富化放在聚合时：应用健康、归属等元数据在 Stage 3 落库前补齐，避免查询时的 join 开销。

七、时间旅行：任意时刻的拓扑重建

“事故发生时调用图长什么样？“全量快照存储成本爆炸，事件溯源回放太慢。方案是三件套组合：

时间窗 aggregator 快照：每个 aggregator 带 startTs 和 endTs，按 entity_id 加时间戳存进图数据库，相当于每 5 分钟一个检查点。
属性级变更追踪：图数据库只存变化过的属性加时间戳，比全实体拷贝省得多，还提供了窗口边界之内的精度。
查询时重建：查时间范围内的 mutation 历史，按序应用，重建拓扑状态。

外加一个聪明设计：查询时再聚合复用摄入时的同一套 aggregator 类，可以做没预计算过的任意 groupby 维度（可用性层级、业务域、部署集群），支持探索式分析而不撑爆存储。

八、原文给的三条通用教训

规模定性地改变一切：每秒 100 次可行的东西在每秒 10 万次失败，变化不是线性的是质变的。不可变结构、单级聚合、gRPC，在小规模下全是对的。
一次只优化一个瓶颈：修 Kafka lag 暴露热点，修热点暴露 GC，修 GC 暴露序列化。这不是失败，是复杂系统的本性。按影响排序，修透一个再修下一个。
分布是扩展性的关键：一致性哈希能分散负载，但挡不住数据本身的幂律分布倾斜。倾斜数据在规模下要多级处理、逐级重新分布。

工程实践联想

背压是降级策略，不是性能特性。 它的价值不在快，在于"慢了也不死不丢”。做异步管线时先想清楚：下游慢了，数据去哪？答案如果是"内存里堆着"或"丢掉”，早晚要还。
数据分区方式决定架构形状。 IPC 一级聚合、网络流三级聚合，差异全在数据进来时分没分对。设计管线前先问：处理这个 key 需要的数据，天然在一起吗？不在，就认命加 shuffle 级。
对"最佳实践"保持工程师式的不敬。 不可变数据结构、gRPC、二进制序列化，三个正确常识在这套系统里全被推翻了——但每次推翻都有 profiling 数据背书，且范围克制（可变只用于热路径）。违反常识不可怕，凭感觉违反才可怕。
优化是一条链，不是一次战役。 修一个瓶颈暴露下一个，这是吞吐上升的必然结果。所以别指望"性能优化专项"一劳永逸，把 profiling 工具链（async-profiler、heap dump、GC 日志）和边界监控变成日常设施才是正解。
白嫖现有基础设施是高级的架构品味。 拿服务注册中心当集群成员来源，零协调成本拿到动态一致性哈希。新组件引入前先盘一遍手里已有的东西能替代什么——他们连消息队列都因此省掉了。

本篇小结

核心架构：流式优先加背压（Kafka 当缓冲池，慢下来但不丢不崩）；网络、IPC、追踪三层物理隔离存储，查询时并行合并。
三级聚合管线：Stage 1 时间窗聚合、Stage 2 按中间件 shuffle 并解析双跳、Stage 3 富化持久化。一个设计同时解决中间件解析和热点节点。
关键妥协：热路径可变数据结构（堆分配降 50%+）、gRPC 换 SSE、序列化统一 JSON——全是测量驱动的反常识决策。
时间旅行：窗口快照加属性级 mutation 加查询时重建，任意时刻拓扑可查，还能查询时再聚合做任意维度 groupby。
方法论：规模改变结论；瓶颈是瀑布，修一个露一个；优化是连续过程，测量是唯一指南针。

参考资料

原文：Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned（Netflix TechBlog，作者 Parth Jain、Rakesh Sukumar、Yingwu Zhao、Renzo Sanchez-Silva、Nathan Fisher）。
文中涉及的关键技术：Apache Pekko（反应式流实现，Akka fork）、async-profiler（JVM 采样分析器，热点与 GC 根因定位的主力工具）、Reactive Streams（背压协议规范）。
系列第一篇介绍多源拓扑的 what 与 why，第三篇将讲追踪层与统一查询，均在 Netflix TechBlog 连载。

Netflix 实时服务拓扑图笔记：把「谁依赖谁」从考古变成活地图

Fri, 29 May 2026 10:00:00 +0800

Netflix 实时服务拓扑图笔记：把「谁依赖谁」从考古变成活地图

原文：From Silos to Service Topology: Why Netflix Built a Real-Time Service Map（Netflix Tech Blog，2026-05-29，作者 Parth Jain 等）目标读者：维护过微服务系统、半夜被告警叫醒过、对着一堆监控面板猜「到底谁挂了」的后端工程师。阅读目标：搞清楚 Netflix 为什么认为「依赖关系」值得单独立项做一套系统，三路数据源怎么互补，以及那套「网络中间人解析」管线在解决什么问题。

一、问题：信号很多，地图没有

原文开场是经典的凌晨三点剧本：工程师被 page 醒，某个关键服务错误率升高，用户观影体验受损。在几千个微服务支撑的系统里，这时候要回答的问题其实非常朴素，但谁也答不快。

Netflix 做了一件值得学的事：他们没有拍脑袋立项，而是分析了四年间工程师提交的数千条支持请求，发现高频问题惊人地一致：

我的上游和下游依赖是谁？
这个故障是我自己的问题，还是我依赖的某个服务坏了？
我下线这台服务做维护，会影响谁？该通知哪些团队？
为什么这个服务在我的指标里显示为「Unknown」？
最近我的调用链路上有什么变化，能解释这个行为吗？

全是依赖问题。而传统可观测性三件套各自只给碎片：指标告诉你症状，日志告诉你单个服务在干嘛，追踪告诉你单次请求怎么流的——没有一样东西能告诉你稳态下整张依赖网长什么样。工程师得在凌晨三点用脑子把多个工具的信息缝起来，慢、易错、压力大。

这里有个判断很准：缺的不是信号，是关系。信号再多，回答不了「谁连着谁」这种结构性问题。

二、踩过的坑：五条教训

Netflix 不是第一次干这件事。原文坦承他们试过外部图数据库、商业平台、各种存储和内部原型，每轮迭代换来一条教训：

实时性是生死线：服务每天部署多次的环境里，几小时前的拓扑图是考古资料，不是可观测性。
规模改变一切：能装几千节点的方案，到 Netflix 的服务数量和流量规模会撞墙。
集成是关键：不能要求工程师离开现有工作流去学一套新工具。
数据质量差比没有更糟：错误或不完整的依赖信息会在事故中把人带向错误结论。
单一视角讲不全：网络连接数据缺应用上下文，应用指标只覆盖做了埋点的服务，必须多源合并。

这五条几乎条条是钱烧出来的，尤其是第四条——一个会撒谎的地图比没有地图更害人。

三、核心设计：三个真相来源，三张物理隔离的图

这是全文最有分量的一个架构决策。Netflix 的结论是：没有任何单一数据源能讲完整的依赖故事，所以他们用三路互补的数据各自建一张图：

flowchart TD
    subgraph SRC["三路数据源"]
        EB["eBPF 网络流<br/>内核态抓真实连接"]
        IPC["IPC 指标<br/>应用埋点 gRPC GraphQL REST"]
        TR["端到端追踪<br/>采样后的真实请求路径"]
    end
    subgraph G["三张物理隔离的图"]
        G1["网络图<br/>图数据库分区一<br/>覆盖全 但无应用语义"]
        G2["应用图<br/>图数据库分区二<br/>有端点细节 但只覆盖已埋点服务"]
        G3["请求图<br/>列式存储<br/>真实行为 但有采样盲区"]
    end
    EB --> G1
    IPC --> G2
    TR --> G3
    G1 --> U["统一视图<br/>并行查询三路 合并节点与边<br/>亚秒级返回"]
    G2 --> U
    G3 --> U
    style U fill:#e8f5e9

三路的价值与短板正好互补：

eBPF 网络流（网络层）：在内核层抓连接记录，不管应用有没有埋点，每个服务都在图上——这是完整性的地基。短板是没有应用上下文：你知道 A 连了 B 的 IP 和协议，但不知道调的是哪个 API 端点。
IPC 指标（应用层）：埋点服务发出的进程间通信指标，能看到具体端点、错误率、延迟分布、协议细节。短板是只覆盖做了埋点的服务。
端到端追踪（请求层）：不是「A 可以调 B」，而是「A 在处理这个具体请求时确实调了 B」，能捕获条件分支和特性开关带来的真实运行时行为。短板是采样——冷门代码路径在聚合视图里可能看不见。

工程实现上有个细节值得注意：三张图物理隔离——网络层和 IPC 层各在图数据库的一个分区，追踪层用列式存储（为分析型查询优化）。隔离换来两个好处：各层独立演进，查询时可以三路并行、最后合并结果，即使三层全合并也能做到亚秒返回。

这个设计翻译过来就是一句话：完整性靠网络流兜底，语义靠 IPC 补齐，行为真实性靠追踪验证。任何单源方案都在这三者里缺一角。

四、数据管线：三级聚合与「中间人解析」

架构层面，流日志从 Kafka 到可查的图要走这样一条管线：

flowchart LR
    K["多区域 Kafka<br/>持续消费流日志"] --> P["Pekko Streams<br/>分布式处理 自动分区<br/>天然背压"]
    P --> S1["第一级 初始聚合<br/>从 Kafka 进来的原始流"]
    S1 --> S2["第二级 中间人解析<br/>识别 LB NAT 网关 代理<br/>把两跳拼回一跳"]
    S2 --> S3["第三级 最终聚合<br/>叠加健康状态"]
    S3 --> DB["图数据库<br/>建在分布式 KV 之上<br/>高吞吐多跳遍历"]
    DB --> API["gRPC API<br/>多跳遍历 按层过滤<br/>分页 亚秒响应"]
    style S2 fill:#fff3cd

三个点值得展开：

处理框架用 Apache Pekko Streams（Akka 的 fork），看重的是分布式容错、自动把负载分区到 Auto Scaling Group、以及响应式流自带的背压处理。
三级聚合里最聪明的是第二级。网络流日志记录的是逐跳的物理连接：App A → 负载均衡器 → App B，或者经过 NAT 网关。工程师要的不是这个，是 App A → App B 这条应用级直连边。第二级负责识别出负载均衡器、NAT 网关、API 网关、代理这些「网络中间人」，把它们的入向流和出向流拼起来，还原出真正的应用到应用路径。
分三级还有个副作用：防热点。当某些应用或中间人的流量是其他节点的上百倍时，把聚合分散到多个阶段执行，热点不会压垮单点。

查询侧是 gRPC API：多跳遍历、按可用性等级（Tier 0、Tier 1 之类）和业务域过滤、大结果集分页、亚秒响应。UI 和 API 并重——工程师用界面排查，自动化系统（韧性框架、爆炸半径计算器、事故响应机器人）走 API。

五、工程师拿到了什么

系统落地后的能力清单，按原文压缩：

看依赖：任意服务的上下游，可按可用性等级和业务域过滤，可切换统一视图或单源视图。
跳信号：从图上任意节点直接跳到对应工具的日志、追踪、指标，不用再手动拼服务名和时间窗。
算爆炸半径：下线维护或大改之前，先看清楚影响谁、通知谁、盯什么。
叠健康状态：拓扑上直接叠加哪些服务正在出问题，快速判断「我看到的故障是不是从别处传过来的」。
程序化查询：Platform Modernization 团队用它验证直播关键服务的整条依赖链都打了正确的可用性等级标记——拓扑成了合规校验的数据源。
时间旅行：查历史上某个时间点的拓扑长什么样。实现上没有每个时间片存一份（存储会爆炸），而是用各层专用的聚合器跨时间窗口累积，需要历史视图时再重建。

最后这条「时间旅行」是我觉得最有味道的：事故排查的黄金问题「故障开始前，我的依赖图变了什么」终于被变成一条查询，而不是靠翻部署记录和记忆。

六、活的地图，和下一步

Netflix 反复强调「living map」这个词：新调用关系出现就近实时上图，调用停止的边会从图里淡出，部署改变行为就改变图。关键承诺是——工程师可以相信图上画的就是现实，而不是某个人对架构的想象。

路线图上的三件事：

变更事件叠加：把部署、配置变更标在拓扑图上，依赖关系和「什么时候改了什么」同框，相关性分析会容易得多。
更丰富的上下文：更多端点级细节、协议信息、网络路径信息。
自动根因分析：一个智能体持续爬拓扑图、跨依赖关联故障、理解历史模式、自动给出疑似根因——拓扑图是这类智能自动化的知识图谱地基。

第三条值得划线：他们不是在说「接个 LLM 上去问答」，而是在说「先把依赖关系建成结构化、实时、可查询的图，智能体才有爬的地面」。这个顺序是对的。

七、工程实践联想

立项之前先做求助记录考古。Netflix 拿四年的支持工单说话，高频问题清单就是需求文档。多数内部平台立项靠的是平台团队自己的痛感，而不是用户的——「我觉得你需要」和「数据说你在问」做出来的东西，采纳率天差地别。
「信号够多」不等于「可观测」。指标、日志、追踪三件套回答的都是单点或单次的问题，依赖关系这种结构性知识需要单独建模、单独存储。如果你的团队排查故障还在靠「老张知道这条链路」，那就是缺这一层。
多源互补是处理「讲不全」问题的标准答案。任何单一采集手段都有盲区：埋点有覆盖率问题，内核抓包有语义问题，采样有冷门路径问题。与其追求一个完美的源，不如让几个不完美的源互相兜底——这个思路对做 AI Agent 的上下文采集同样成立。
「中间人解析」是被低估的脏活。基础设施里到处是 LB、网关、代理，原始数据永远带着这些噪音。谁能把物理路径还原成逻辑路径，谁的数据才可行动。做链路分析、做 RAG 的数据清洗，都会遇到同构的问题。
图建好了，Agent 才有事可做。Netflix 把自动根因分析放在路线图的末尾而不是开头，因为智能体的前提是有一张实时、准确、可编程查询的图。这对「AI + 运维」的喧嚣是一盆冷水：先修地基，再谈智能。

本篇小结

问题：微服务规模下，凌晨三点的工程师回答不了「谁依赖谁、爆炸半径多大、故障源在哪」；四年数千条工单证明这是最痛的缺口。
方案：三路数据源各建一图、物理隔离、并行查询后合并——eBPF 网络流保完整性，IPC 指标保应用语义，分布式追踪保真实行为。
管线：多区域 Kafka → Pekko Streams → 三级聚合（核心是第二级的网络中间人解析，把 LB/NAT/代理的两跳还原成应用级直连边）→ 图数据库（建在分布式 KV 上）→ 亚秒级 gRPC API。
能力：依赖可视化、跳转详细信号、爆炸半径、健康叠加、程序化查询、基于时间窗聚合的历史拓扑（时间旅行）。
哲学：过时的拓扑图是考古不是可观测性；地图必须反映现实而非设计文档；单一数据源永远讲不全依赖关系。
预告：这是系列第一篇，下一篇讲规模化落地的工程硬题——Kafka 消费延迟、GC 停顿、响应式流调试、热点治理。

参考资料

From Silos to Service Topology: Why Netflix Built a Real-Time Service Map（Netflix Technology Blog，2026-05-29，原文）
eBPF 官方文档（内核态可编程观测技术，网络层数据源的基础）
Apache Pekko（Akka 的开源 fork，文中分布式流处理框架）
OpenTelemetry Tracing（分布式追踪的通用概念背景，文中请求层数据源对应物）

视频系统 DDD 实战：巴西 IPTV 项目的领域拆分

Fri, 23 Aug 2024 17:00:00 +0800

视频系统 DDD 实战：巴西 IPTV 项目的领域拆分

2021 年到 2025 年，我负责面向巴西市场的 IPTV 视频点播系统。这是一个用户量过百万、业务持续演进的系统。在几次大的产品迭代中，我们引入了领域驱动设计（DDD）来控制系统复杂度。这篇文章会完整复盘当时的领域拆分过程。

一、项目背景

系统核心功能：

视频上传：支持 tus / FTP / 网盘 / m3u8 等多种来源
视频转码：h264 / h265 多码率输出
DRM 加密：永新 / 自研加密方案
元数据管理：同步 IMDb / TMDB / PP 等外部数据源
播放列表：专题、分类、推荐
播放鉴权：用户权限、设备管理、防盗链

服务用户：200 万+，峰值日活 40 万。

二、为什么需要 DDD？

2.1 早期的问题

系统最初是一个单体应用，模块按技术分层组织：

controller/
service/
dao/
entity/

这种结构在业务简单时没问题，但随着功能增加，开始出现：

一个需求改动涉及多个「层」，改哪里不确定
业务逻辑散落在 Service 中，相似功能重复实现
转码、鉴权、元数据互相耦合，改一个模块影响多个模块
新成员上手慢，需要全局理解才敢改代码

2.2 DDD 带来的改变

DDD 不是银弹，但它帮我们做了两件事：

按业务边界组织代码，而不是按技术分层
显式定义领域概念，让业务逻辑有明确的归属

三、领域划分

3.1 核心域识别

我们先识别出系统的核心业务域：

flowchart TD
    content["内容域 (Content)<br/>媒资管理、视频文件、转码任务、DRM 加密"]
    metadata["元数据域 (Metadata)<br/>影片信息、演员、分类、标签、外部数据源同步"]
    playback["播放域 (Playback)<br/>播放鉴权、播放地址生成、防盗链、码率适配"]
    user["用户域 (User)<br/>用户账户、订阅、设备、播放历史"]
    recommendation["推荐域 (Recommendation)<br/>播放列表、专题、个性化推荐"]
    billing["计费域 (Billing)<br/>套餐、订单、支付、用量统计"]
    content --- metadata --- playback --- user --- recommendation --- billing

3.2 域间关系

flowchart LR
    playback["播放域"] -- 依赖 --> content["内容域"]
    playback -- 依赖 --> user["用户域"]
    recommendation["推荐域"] -- 依赖 --> metadata["元数据域"]
    recommendation -- "依赖（获取热门数据）" --> playback
    billing["计费域"] -- 依赖 --> user
    metadata -- 依赖 --> external["外部数据源"]

依赖方向尽量保持单向，避免循环依赖。

四、内容域详细设计

内容域是最复杂的域之一，我们以它为例展开。

4.1 聚合根设计

flowchart TD
    root["MediaAsset（媒资聚合根）"]
    file["MediaFile（视频文件）"]
    raw["原始文件"]
    transcoded["转码后文件（多码率）"]
    drmfile["DRM 加密文件"]
    job["TranscodingJob（转码任务）"]
    license["DrmLicense（DRM 许可证信息）"]
    root --> file
    file --> raw
    file --> transcoded
    file --> drmfile
    root --> job
    root --> license

MediaAsset 是聚合根，外部系统只能通过它访问内部实体。

4.2 关键领域事件

内容域会产生大量领域事件，其他域可以订阅：

事件	含义	订阅方
`MediaAssetUploaded`	媒资上传完成	转码服务
`TranscodingCompleted`	转码完成	内容域自身、播放域
`DrmEncryptionCompleted`	DRM 加密完成	播放域
`MetadataSynced`	元数据同步完成	推荐域
`MediaAssetPublished`	媒资发布上线	推荐域、搜索服务

4.3 状态流转

媒资从上传到发布的状态机：

flowchart TD
    UPLOADED --> PENDING_TRANSCODE --> TRANSCODING --> PENDING_DRM --> DRM_ENCRYPTED --> PENDING_METADATA --> METADATA_READY --> FINAL["PUBLISHED / REJECTED"]

每个状态变更都通过领域事件触发下一步操作。

五、分层架构

每个领域内部采用 DDD 经典四层架构：

flowchart TD
    ui["用户接口层<br/>REST Controller / DTO"]
    app["应用层<br/>Application Service / 用例编排"]
    domain["领域层<br/>Entity / Value Object / Domain Service / Repository Interface / Domain Event"]
    infra["基础设施层<br/>Repository Impl / MQ Client / External API Client / DB / Cache"]
    ui --- app --- domain --- infra

5.1 领域层示例

public class MediaAsset {
    private MediaAssetId id;
    private String title;
    private MediaStatus status;
    private List<MediaFile> files;
    private List<TranscodingJob> transcodingJobs;

    public void upload(MediaFile file) {
        this.files.add(file);
        this.status = MediaStatus.UPLOADED;
        registerEvent(new MediaAssetUploadedEvent(this.id));
    }

    public void completeTranscoding(TranscodingJob job) {
        this.transcodingJobs.add(job);
        this.status = MediaStatus.TRANSCODING_COMPLETED;
        registerEvent(new TranscodingCompletedEvent(this.id, job.getOutputFiles()));
    }
}

5.2 防腐层设计

与外部系统（IMDb / TMDB / PP）对接时，使用防腐层（Anti-Corruption Layer）：

public interface MetadataSourceClient {
    ExternalMetadata fetch(String externalId);
}

// IMDb 适配器
public class ImdbClientAdapter implements MetadataSourceClient {
    private final ImdbApiClient imdbClient;

    @Override
    public ExternalMetadata fetch(String externalId) {
        ImdbResponse response = imdbClient.fetch(externalId);
        return MetadataConverter.fromImdb(response);
    }
}

这样外部 API 的数据结构变化不会直接影响到我们内部的元数据模型。

六、微服务拆分过程

6.1 第一次拆分：按技术边界

早期我们按技术栈拆：

upload-service
transcoding-service
metadata-service
playback-service

结果导致一个业务操作要跨多个服务，分布式事务复杂。

6.2 第二次拆分：按领域边界

调整后按 DDD 领域拆分：

content-service（内容域）
metadata-service（元数据域）
playback-service（播放域）
user-service（用户域）
recommendation-service（推荐域）
billing-service（计费域）

每个服务有清晰的业务边界和聚合根。

6.3 服务间通信

场景	通信方式	说明
领域事件传播	RocketMQ	异步、最终一致
同步查询	HTTP / gRPC	强一致查询
配置/字典数据	Redis 缓存	高频读取

七、领域事件实现

7.1 事件定义

public class TranscodingCompletedEvent extends DomainEvent {
    private final MediaAssetId mediaAssetId;
    private final List<FileUrl> outputFiles;
    private final Instant completedAt;
}

7.2 事件发布

领域层只负责注册事件，应用层统一发布：

@Transactional
public void handleTranscodingCallback(TranscodingJobId jobId, List<FileUrl> outputs) {
    MediaAsset asset = mediaAssetRepository.findByJobId(jobId);
    asset.completeTranscoding(new TranscodingJob(jobId, outputs));

    mediaAssetRepository.save(asset);
    eventPublisher.publish(asset.getDomainEvents());
    asset.clearDomainEvents();
}

7.3 事件消费

@Component
public class PlaybackEventListener {

    @RocketMQMessageListener(topic = "content-events", selectorExpression = "TranscodingCompleted")
    public class Listener implements RocketMQListener<TranscodingCompletedEvent> {
        @Override
        public void onMessage(TranscodingCompletedEvent event) {
            playbackService.preparePlayUrls(event.getMediaAssetId(), event.getOutputFiles());
        }
    }
}

八、几次关键演进

8.1 从单体到领域化单体

第一步不是拆微服务，而是先在单体内部按领域组织代码包：

com.ftmao.iptv.content
com.ftmao.iptv.metadata
com.ftmao.iptv.playback

这样可以在不引入分布式复杂度的前提下，先验证领域划分是否合理。

8.2 从同步调用到事件驱动

转码完成后，原本播放域通过接口轮询内容域查询状态。后来改为内容域发布 TranscodingCompleted 事件，播放域订阅。

收益：

内容域和播放域解耦
新增订阅方不需要改内容域
系统扩展性更好

8.3 引入 CQRS 处理播放查询

播放接口对性能要求很高，我们单独做了读模型：

写模型：MediaAsset 聚合根
读模型：Redis 中的播放信息缓存

当内容发布或更新时，通过事件同步更新读模型。

九、踩过的坑

9.1 领域划分过细

早期我们划分了 10 多个领域，导致服务数量爆炸，运维成本剧增。

教训：领域数量要匹配团队规模。小团队 4-6 个领域足够。

9.2 领域事件丢失

消息队列配置不当，出现过领域事件丢失，导致播放域看不到新发布的内容。

教训：关键领域事件必须持久化，支持重放和补偿。

9.3 贫血领域模型

很多「DDD」项目最后变成了 Transaction Script 套壳，实体只有 getter/setter。

教训：要把业务规则和状态变更放在领域对象里，而不是 Service 里。

9.4 过度设计聚合根

一开始想把所有内容相关的东西都放到 MediaAsset 聚合根里，结果聚合根过大，事务边界混乱。

教训：聚合根要小而聚焦，跨聚合用领域事件协作。

十、效果与反思

10.1 量化效果

指标	优化前	优化后
新需求平均改动文件数	40 个	20 个
线上因耦合导致的 Bug	10 次/月	2 次/月
新成员独立上手时间	3 周	1 周

10.2 核心反思

DDD 不是先拆分微服务，而是先拆清楚业务边界。微服务是结果，不是起点。
领域事件是域间协作的核心，但事件丢失和顺序问题必须重视。
不要追求完美的领域模型，先有一个可用的模型，再迭代优化。
DDD 需要团队共识，不是架构师一个人画几张图就行的。

十一、总结

巴西 IPTV 项目让我对 DDD 有了真实的体感。它不是教科书上的概念，而是解决复杂业务系统演化问题的工程方法。

对于视频系统这类业务复杂、流程长、多团队协作的系统，DDD 能带来的最大价值是：

让每个业务概念都有清晰的归属
让系统变更的影响范围可控
让新成员能更快理解业务

如果你也在做 DDD 实践，欢迎在评论区交流领域划分和事件驱动的经验。

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

Tue, 20 Jul 2021 10:00:00 +0800

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

这是我 2021 年做的一套完整电商系统 starmall（六爻星辰）：微信小程序端 + Java 后端 + PC 管理后台，支持商品购买、老师咨询时段预约、择吉日查询、在线咨询等业务。整理开源出来，写篇文章做一次完整的技术复盘。

前端（uni-app 小程序）：https://gitee.com/soulnew/starmall
后端（Java + 管理端）：https://gitee.com/soulnew/crm_server
技术栈：Spring Boot 2.2 + MyBatis-Plus + MySQL + Redis / uni-app + uView / Vue 2 + Element UI（管理端）
说明：后端是在开源商城 CRMEB Java 版 基础上二次开发的，分销/秒杀/拼团/砍价等营销能力来自底座，预约系统、择吉日、名片、咨询聊天等是自研部分

一、整体架构

graph TD
    MP["微信小程序端<br/>starmall uni-app + uView"] -->|"https://ftmao.com/api/front/**"| API["SpringBoot 单体后端<br/>62 个 Mapper / 23 个前台 Controller"]
    H5["H5 / App<br/>uni-app 多端编译"] --> API
    ADMIN["PC 管理后台<br/>Vue 2 + Element UI + ECharts"] -->|"后台接口"| API
    API --> MYSQL["MySQL 5.7<br/>62 张表 Druid 连接池"]
    API --> REDIS["Redis<br/>token / 订单缓存 / 任务队列 / 配置缓存"]
    API --> WX["微信开放平台<br/>登录 / 支付 V2 / 订阅消息"]
    API --> QN["七牛云 OSS<br/>图片上传"]
    API --> QY["企业微信机器人<br/>部署结果通知"]
    MP -->|"wss://... websocket"| CHAT["咨询聊天服务"]

代码规模：后端约 850 个 Java 文件、12.6 万行；小程序前端业务代码约 1.2 万行；数据库初始化 SQL 全量在仓库里，共 62 张表。后端按业务分包：front（小程序接口）、order/payment、marketing、seckill、task（定时任务）、wechat，以及自研的 appoint（预约）、lunar（黄历）等模块。

二、功能介绍

2.1 商品购买全流程

标准的商城闭环：商品详情（多规格 SKU）→ 立即购买/加购物车 → 确认订单（优惠券、积分抵扣、运费计算）→ 创建订单 → 微信支付 → 轮询支付结果 → 收货评价 → 退款/售后。支付是真实对接的微信支付 V2——后端手工实现 XML 报文 + MD5 签名调统一下单（WeChatPayServiceImpl，746 行），前端弹起 wx.requestPayment，不是 mock。

此外还支持：余额支付、运费模板（满额包邮/指定城市包邮/按件数重量体积三种首续费）、物流查询、自提核销码、再次下单。营销玩法（秒杀、砍价、拼团、优惠券）来自 CRMEB 底座，一应俱全。

2.2 老师咨询时段预约（自研核心）

这是这个项目区别于普通商城的地方——卖的不只是实物商品，还有"老师的时间"：

商品分类为"老师类"时，商品详情页出现一个时段选择器（每天 6 个时段：9/11/13/15/17/19 点）；
teacher_plan 表按「日期 × 时段」预生成号源，被约走的时段前端置灰；
下单时携带 teacherPlanId，创建订单的同一个事务里把该时段标记为已约——号源占用和订单创建要么一起成功要么一起回滚，不会出现"钱付了时段没了"；
号源由定时任务 TeacherPlanTask 每 8 小时自动向前补齐未来 8 天，并清理过期的空闲号源。

2.3 其他自研功能

择吉日查询：4.7 万行黄历数据入库（lunar 系列表），按"宜"事反查吉日，比如查"最近适合搬家的日子"；
在线咨询：基于 WebSocket 长连接的实时聊天，支持文字/语音/图片消息（详见第三章「长连接聊天」）；
老师名片、文章资讯、签到积分、充值、小程序订阅消息提醒；
管理后台：商品/订单/营销/分销/财务/短信/按钮级权限/数据统计大屏（ECharts）。

三、后端能力全景

后端虽然是 SpringBoot 单体，但能力面相当完整：前台 23 个 Controller、62 个 MyBatis Mapper，按业务分包组织：

graph TD
    subgraph M1["业务模块"]
        A1["front 前台接口<br/>23 个 Controller"]
        A2["order / payment<br/>订单与支付"]
        A3["marketing / seckill / bargain / combination<br/>优惠券 秒杀 砍价 拼团"]
        A4["appoint / lunar / businessCard<br/>预约 择吉日 名片（自研）"]
        A5["finance / statistics / export<br/>充值提现 数据统计 Excel 导出"]
        A6["wechat / wechatMessage / sms<br/>微信生态与短信"]
        A7["task<br/>定时任务体系"]
    end
    subgraph M2["公共层"]
        B1["拦截器链<br/>前台 Token / 后台 Token+权限 / Swagger"]
        B2["工具层 RedisUtil / WxPayUtil / CrmebUtil"]
        B3["ThreadLocal 上下文传递当前用户"]
    end
    A1 --> B1
    A2 --> B2
    B1 --> B3

商城主链路之外，后端还有一批容易被忽略的能力：

微信公众号消息自动回复：wechatMessage 模块支持文字/语音/图片/图文四种回复类型，关注、取关、扫码等事件都有对应处理；
模板消息与订阅消息：小程序订阅消息、公众号模板消息的增删查与群发，且发送走异步任务（AsyncWeChatProgramTempMessage 等），不阻塞主流程；
渠道二维码与素材管理：带参数的推广二维码、微信素材的上传管理；
数据导出与统计：POI 实现的 Excel 导出、交易/商品/用户多维统计接口（配合管理端 ECharts 大屏）；
短信与物流：短信验证码/通知、快递物流轨迹查询；
接口文档：Swagger 在线文档 + 仓库内置 admin/app/公共三份离线接口文档。

3.1 长连接聊天（WebSocket）架构

在线咨询是这个系统的"第二前台"，采用的是 WebSocket 长连接 + HTTP 接口的组合方案。部署上两个服务跑在同一台服务器，由 nginx 按路径前缀分流：

graph TD
    MP["小程序聊天页<br/>pages/chat"] -->|"wss://.../websocket/userId/sessionId"| NGX["nginx 按路径分流"]
    MP -->|"HTTP /chat/session/**  /chat/msg/**"| NGX
    MP -->|"HTTP /api/front/**"| NGX
    NGX --> CHAT["聊天服务<br/>WebSocket 长连接 + 会话/消息接口"]
    NGX --> MALL["商城后端 crm_server<br/>SpringBoot 18080"]

从开源的小程序端实现和接口契约，可以看到这套长连接聊天的几个设计要点：

连接即身份：WebSocket 握手 URL 直接携带 userId/sessionId，连接建立的同时就完成了身份识别与会话路由，不需要额外的登录帧；
实时走长连接，持久化走 HTTP：收发消息走 WebSocket（消息体为 JSON）；会话绑定（session/bindSession）、会话列表、删除会话、历史消息拉取（msg/msgList）都走 /chat/ 前缀的 HTTP 接口——长连接管"实时推送"，HTTP 管"可查询、可回溯"，职责分得很干净；
统一的消息类型协议：contentType 1=文字、2=语音（带 contentDuration 时长）、3=图片（先经 user/upload/image 上传拿到 URL，再把 URL 作为消息内容发出）；
语音消息的移动端交互：按住说话（touchstart/touchend 控制录音起止）、上滑取消（touchmove/touchcancel），体验和微信原生聊天对齐；
发送体验乐观化：消息发出后先本地 push 进消息列表立即上屏，send 的 fail 回调再 toast 兜底提示。

需要如实说明：聊天服务端的代码没有随这两个仓库开源（它部署在同一台服务器上，由 nginx 分流），仓库里能看到的生产实现是小程序端；crm_server 里的 com/im/SocketServer.java 只是当时练手的原生 TCP Socket demo（12345 端口），并非线上实现。

四、技术亮点

4.1 下单幂等：两段式 + 唯一键兜底

小程序网络环境下用户双击、重试、断网重发是常态，下单接口必须幂等。这里用了一个两段式设计：

graph TD
    A["order/confirm 确认订单页"] --> B["订单数据序列化存 Redis<br/>key = md5 当前时间<br/>有效期 60 分钟"]
    B --> C["order/create/orderKey 创建订单"]
    C --> D{"第一步:查库判重<br/>StoreOrder.unique = orderKey"}
    D -->|"已存在"| E["直接返回已有订单<br/>不重复创建"]
    D -->|"不存在"| F{"第二步:校验 Redis 缓存<br/>是否过期/被用过"}
    F -->|"过期"| G["拒绝 提示重新确认"]
    F -->|"有效"| H["事务内创建订单<br/>成功后删除缓存"]

unique 字段是最后的兜底——即使 Redis 挂了、缓存丢了，数据库唯一约束也保证同一个 orderKey 不会建出两张单。

4.2 原子扣库存防超卖

库存扣减没有用"先查后改"，而是一条 SQL 完成：

// setSql + 条件改写，数据库层面原子完成
stock = stock - n   且要求   stock - n >= 0

数据库单行更新的原子性天然挡住并发超卖，不需要分布式锁。秒杀/砍价/拼团场景更复杂：同一事务内要扣活动表 + 活动 SKU 表 + 商品表 + 商品 SKU 表四份库存，任何一步失败整体回滚。

4.3 编程式事务包住整个建单过程

创建订单是个多写操作：扣库存、占预约时段、写订单主表、写订单详情、核销优惠券、写订单日志。代码用 TransactionTemplate 编程式事务（而不是 @Transactional 注解）把这一串操作包起来——好处是事务边界精确可控，不会把整个方法（包括不需要事务的远程调用）都圈进去。订单核心逻辑集中在 OrderUtils.java（1500+ 行）和 OrderServiceImpl.java（近 1000 行）。

4.4 支付回调：防重 + 异步化

微信支付的回调处理（CallbackServiceImpl.weChat，448 行）有几个关键点：

解析 XML、校验 return_code/result_code，按 attach 里携带的 userId + type 区分是订单支付还是充值；
已支付直接返回 SUCCESS——微信会多次重推回调，幂等是回调接口的生死线；
事务内完成 updatePaid（置订单已支付）+ 扣积分 + 拼团状态处理；
后续的"慢动作"——发短信、推订阅消息、分销结算——不放在回调里同步做，而是 lPush 进 Redis 队列异步执行，回调接口尽快给微信返回，避免超时重推。

4.5 没有 MQ：Redis List + 定时任务的务实替代

项目没有引入 RabbitMQ/RocketMQ，而是用 Redis List 当队列 + Spring @Scheduled 定时任务消费，撑起了一整套异步任务体系：

graph LR
    A["下单成功<br/>lPush ORDER_AUTO_CANCEL_KEY"] --> Q["Redis List 队列"]
    P["支付成功回调<br/>lPush 后续动作"] --> Q
    Q --> T1["OrderAutoCancelTask<br/>每分钟消费<br/>超时未支付自动取消 + 回滚库存"]
    Q --> T2["自动收货 / 自动好评"]
    Q --> T3["优惠券过期 / 砍价截止<br/>佣金解冻"]
    Q --> T4["TeacherPlanTask<br/>每8小时补齐号源"]

task/order/ 下共有 8 个定时任务。对这个体量的系统，省掉一个 MQ 的部署运维成本，换来的是完全够用的可靠性——这是小项目技术选型上我很认可的一个取舍。

4.6 鉴权链路：UUID Token + Redis + ThreadLocal

没有用 JWT，而是更传统的方案：登录后签发 UUID 存 Redis（按模块区分 key 前缀），拦截器 FrontTokenInterceptor → CheckFrontToken → TokenManagerImpl 逐级校验，通过后把当前用户放进 ThreadLocal 供全链路取用。管理端是 Token + 权限双拦截器。好处是服务端可随时踢人下线（删 Redis key 即可），这是纯 JWT 做不到的。

4.7 其他值得提的实现

订单快照：下单时把购物车内容序列化成 JSON 存进 StoreOrderInfo.info，之后商品改价改名都不影响历史订单的展示；
运费计算引擎：getOrderPriceGroup 支持满额包邮、指定城市包邮（件数 + 金额双条件）、按件数/重量/体积三种首续计费模式；
XSS 转义：用户输入统一 escapeHtml4；
部署脚本：start.sh nohup 启动 + 轮询日志判断启动成功 + 企业微信机器人推送部署结果——单机部署也搞出了仪式感。

五、复盘与遗憾

底座与自研的边界：秒杀/拼团/砍价/分销这些"重"能力直接复用 CRMEB 底座，把精力集中在业务差异化（预约、择吉日、聊天）上——对个人开发者来说这是正确的杠杆；
单体的局限：所有东西在一个 SpringBoot 应用里，定时任务、支付、前台接口互相影响，量大了必然要拆；
原子扣库存的返回值没检查：setSql 扣减失败（库存不足）时影响的行数为 0，但代码没有校验这个返回值，极端情况下会漏判超卖——这是现在回头看想补的一个洞；
聊天服务端未开源：如第三章所述，长连接聊天的服务端实现没有随仓库开源，小程序端和接口契约是完整的，算是开源的一点遗憾。

六、写在最后

这个项目让我完整走了一遍"真实收钱"的系统该有的样子：幂等、事务、防超卖、回调防重、异步补偿——每一个点背后都是电商系统趟过的坑。代码在 https://gitee.com/soulnew/starmall 和 https://gitee.com/soulnew/crm_server，建库 SQL、接口文档都在仓库里，希望能给做小程序商城的朋友一个可参照的完整样本。

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