架构 on 方糖猫Blog

千人千面 + 无限瀑布流：推荐 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 三层划分）；推荐系统排序漏斗与游标分页为业界通用架构实践。

Ruby on Rails 高级篇：接入 Redis、Elasticsearch、消息队列与大数据组件的工程实践

Mon, 14 Sep 2026 14:00:00 +0800

Ruby on Rails 高级篇：接入 Redis、Elasticsearch、消息队列与大数据组件的工程实践

姊妹篇：《Ruby on Rails 从零基础到精通》——入门篇讲「把功能写出来」，这一篇讲「把系统接出去」。目标读者：已经能独立写 Rails CRUD，现在产品要接搜索、接缓存、接消息队列、接大数据管道，想知道「正确姿势」而不是「能跑就行」的开发者。

入门篇的应用是自包含的：一个 Rails 进程 + 一个数据库就是全世界。真实系统不是这样——搜索要 ES、缓存要 Redis、异步要 MQ、报表要大数据平台。每接一个组件，就多一种故障模式。这一篇的结构：

flowchart LR
    A["一 Redis<br/>缓存 队列 数据结构"] --> B["二 Elasticsearch<br/>搜索与索引同步"]
    B --> C["三 消息队列<br/>RabbitMQ / Kafka"]
    C --> D["四 大数据组件<br/>Spark / Flink / ClickHouse"]
    D --> E["五 通用纪律<br/>超时 重试 熔断 幂等"]
    style E fill:#e8f4e8

前四篇每个组件都回答三个问题：用什么 gem、数据怎么流动、生产上死在哪。第五篇是把前四篇的教训抽象成通用清单——以后接任何新组件，照着过一遍就行。

第一篇 Redis：一个组件，四种角色

Rails 接 Redis 最大的误区是「装个 redis gem 存取字符串」。Redis 在 Rails 生态里实际承担四种完全不同的角色，配置和运维要求都不一样：

flowchart TD
    R[("Redis")]
    R1["角色1 缓存<br/>Rails.cache"] --- R
    R2["角色2 任务队列<br/>Sidekiq"] --- R
    R3["角色3 实时推送<br/>Action Cable"] --- R
    R4["角色4 业务数据结构<br/>计数器/排行榜/锁"] --- R

1.1 角色一：缓存（最常用）

# config/environments/production.rb
config.cache_store = :redis_cache_store, {
  url: ENV["REDIS_CACHE_URL"],
  connect_timeout: 1,     # 连接超时 1s，别用默认的 5s
  read_timeout: 0.5,
  write_timeout: 0.5,
  error_handler: ->(method:, returning:, exception:) {
    # 关键：Redis 挂了降级为「缓存 miss」，而不是整个请求 500
    Sentry.capture_exception(exception)
    nil
  }
}

之后入门篇第六篇讲的 Rails.cache.fetch、俄罗斯套娃缓存全部自动走 Redis。两个生产级要点：

error_handler 必须配。缓存的定位是加速器，Redis 抖动不该打垮主站——miss 只是变慢，异常才是事故。
缓存和队列用不同的 Redis 实例/库。缓存实例可以随便清、可以开 allkeys-lru 淘汰；队列实例丢数据就是丢任务。混在一个实例上，运维策略互相打架。

三大经典问题的 Rails 解法：

问题	解法
穿透（查不存在的数据）	`Rails.cache.fetch` 缓存 nil（`skip_nil: false` 是默认行为，nil 也会被缓存），恶意枚举 ID 时考虑布隆过滤器
击穿（热点 key 过期被并发回源）	`Rails.cache.fetch(key, race_condition_ttl: 10)`——过期后第一个进程回源，其余继续用旧值撑 10 秒
雪崩（大面积同时过期）	TTL 加随机抖动：`expires_in: 30.minutes + rand(300).seconds`

1.2 角色二：Sidekiq 任务队列

入门篇讲过 ActiveJob 的 API，生产上吞吐量要求高的场景底层换成 Sidekiq：

# config/application.rb
config.active_job.queue_adapter = :sidekiq

# config/sidekiq.yml —— 队列优先级：重要队列权重高
:queues:
  - [critical, 3]
  - [default, 2]
  - [low, 1]

Sidekiq 与 ActiveJob 的关系：ActiveJob 是 Rails 的标准接口（可换后端），Sidekiq 是高性能实现。建议业务代码只写 ActiveJob API，但有两件事只有原生 Sidekiq 做得好：定时任务（sidekiq-cron / sidekiq-scheduler）和中间件链（统一埋点、限流）。队列 Redis 的内存要按「任务堆积三天不丢」规划，持久化开 AOF。

1.3 角色三：Action Cable 实时推送

入门篇的 Turbo Streams 底层就是 Action Cable，默认用 Redis pub/sub 做进程间广播：

# config/cable.yml
production:
  adapter: redis
  url: <%= ENV.fetch("REDIS_CABLE_URL") %>

多实例部署时这个是必须的（甲请求打到实例 A，乙的浏览器连着实例 B，靠 Redis 广播互通）。流量大了可以换 anycable（Go 实现，单机连接数高一个数量级），Rails 代码不用改。

1.4 角色四：业务数据结构

排行榜、计数器、分布式锁、去重集合——这些直接用 Redis 数据结构，比塞进 MySQL 合适：

# Kredis：Rails 官方出品的 Redis 数据结构封装
class Post < ApplicationRecord
  kredis_list :recent_viewer_ids, limit: 100
  kredis_counter :views
  kredis_unique_list :tag_cache, limit: 50
end

post.views.increment                    # INCR，原子计数
post.recent_viewer_ids.prepend(user.id) # 自动截断到 100

分布式锁用 redis-mutex 或 Sidekiq 生态的 sidekiq-unique-jobs（防止同一任务并发执行，这是任务系统最常用的锁场景）。

1.5 追问：有没有 JetCache 那种「本地 + Redis」两级缓存？

Java 的 JetCache/多层缓存方案（Caffeine 进程内 + Redis 远端 + pub/sub 广播失效）在 Ruby 生态没有对等的成熟 gem，原因在部署模型：Java 是单进程多线程，Caffeine 缓存被整个 JVM 共享，L1 收益巨大；Ruby 应用服务器是多进程模型（Puma 5 个 worker = 5 个独立进程，内存互不相通），进程内缓存每个 worker 各存一份，命中率被摊薄、失效还得跨进程广播——收益/复杂度比不划算，生态便没有收编出「JetCache.rb」。

Rails 的现实替代分三层：

请求级 L1（内建，你已经在用）：所有 ActiveSupport::Cache store 都内置 LocalCache 策略——同一次请求内重复读同一个 key 走进程内存，不打 Redis，请求结束自动清空，无一致性问题。它解决的是「一次请求内 N+1 次读缓存」。
跨请求 L1（手卷，二十来行）：配置/字典类「变很少、读极多」的数据，用 Concurrent::Map + 短 TTL + Redis pub/sub 主动失效：

class ConfigCache
  TTL = 30  # 短 TTL 兜底：pub/sub 丢消息最多脏 30s

  def self.fetch(key)
    entry = store[key]
    return entry[:value] if entry && entry[:exp] > Time.now
    store[key] = { value: yield, exp: TTL.seconds.from_now }
    store[key][:value]
  end

  def self.store = (@store ||= Concurrent::Map.new)

  # 启动时订阅失效广播（多 worker 各自订阅）
  def self.listen(redis)
    Thread.new { redis.subscribe("config:invalidate") { |m| store.delete(m.message) } }
  end
end

Rails 8 的官方答案：Solid Cache 用本地 NVMe 当「超大 L1」：与其在内存里抠几千条 entry，不如把缓存放本机 SSD（SQLite 本地文件）——容量大两个数量级、无网络往返、持久化重启不丢。思路是不优化单次读取延迟，而是把「几乎什么都缓存」变便宜。

第二篇 Elasticsearch：搜索是数据同步问题

Rails 接 ES，写查询语法是简单的一半，难的一半是「MySQL 里的数据怎么进 ES、怎么保持一致」。

2.1 Gem 选型

Gem	特点	建议
Searchkick	封装好、中文分词/高亮/聚合开箱即用	大多数项目的首选
`elasticsearch-model`	官方 gem，贴近原生 DSL	查询复杂、需要完全控制力时

以 Searchkick 为例：

class Post < ApplicationRecord
  searchkick word_middle: [:title],   # title 支持中间匹配（类 LIKE %x%）
             settings: { number_of_shards: 1 }

  # 控制哪些字段进 ES、以什么形态进
  def search_data
    {
      title: title,
      body: body,
      user_name: user.name,      # 关联字段打平进索引
      published_at: published_at,
      comment_count: comments.size
    }
  end
end

# 中文分词：ES 集群装 IK 插件后
# Post.search "视频", fields: [:title], 自动走配置的分析器
Post.search "ruby 教程",
            where: { published_at: { lt: Time.current } },
            order: { comment_count: :desc },
            page: params[:page], per_page: 20

search_data 是核心设计点：ES 文档是反范式的。关联表的字段（作者名、评论数）要打平进文档，否则查询时要回库 join，ES 的意义就没了。代价是：用户名改了，所有相关文档都要重建索引——这就是下一节的问题。

2.2 索引同步：三种策略的取舍

flowchart TD
    W["业务写入 MySQL"] --> S1["策略A Model 回调<br/>同步写 ES"]
    W --> S2["策略B 后台 Job<br/>异步写 ES"]
    W --> S3["策略C CDC<br/>binlog 监听管道"]

策略 A：回调同步写（Searchkick 默认 after_commit）。简单强一致，但 ES 抖动直接拖慢/打挂业务写入，只适合内部系统。
策略 B：回调只入队，Job 异步写（Searchkick 配置 Searchkick.callbacks = :async，或自写 after_commit { ReindexJob.perform_later(self) }）。大多数项目的正确选择：写入不被 ES 拖累，失败可重试。注意 Job 里要重新从 DB 读数据再写 ES（防止任务执行时数据已过期，写入陈旧版本）。
策略 C：CDC 管道（MySQL binlog → Canal/Debezium → Kafka → 消费写 ES）。业务代码零侵入，适合写入量大、文档来源多的大系统，代价是多维护一条数据管道。

2.3 零停机重建索引

Mapping 变更（加字段、改分词）必须重建索引。标准流程靠别名：

# 1. 建新索引 posts_v2，全量灌数据
Post.reindex  # Searchkick 自动建带时间戳的新索引并切换别名

# 底层原理：读永远走别名 posts → 指向 posts_v1 或 posts_v2
# reindex 完成后别名原子切换，全程无读中断

Searchkick 的 reindex 默认就是这个模式，手工玩原生 API 时记住同一原则：读别名，不写别名；切换原子操作。

2.4 生产上死在哪

写放大：热门对象高频更新（计数器、状态），每次都触发 reindex → 把高频字段拆出搜索文档，或改用 update 部分更新。
深分页：from + size 超过 1 万直接报错，列表导出场景用 scroll 或 search_after。
ES 当主库用：ES 不是数据库——近实时（默认 1s 刷新）、无事务。写后立刻要读的场景，读 MySQL 兜底，别调 refresh 硬扛。

第三篇消息队列：ActiveJob 不是 MQ

先澄清一个普遍误解：ActiveJob/Sidekiq 是「任务队列」，不是「消息队列」。两者的区别决定了选型：

	任务队列（Sidekiq）	消息队列（RabbitMQ/Kafka）
语义	「替我执行这段代码」	「广播一个事实，谁关心谁消费」
消费方	只有自己系统的 worker	可以是任意多个异构系统
典型场景	发邮件、生成报表	订单已支付 → 通知库存/物流/积分/大数据

Rails 内部异步用 ActiveJob 就够了；当事件的消费者不止你的 Rails 应用（要对接 Java 服务、数据团队、第三方），才需要真 MQ。

3.1 RabbitMQ：可靠投递优先

# bunny 是 Ruby 的 RabbitMQ 客户端
conn = Bunny.new(ENV["RABBITMQ_URL"]).tap(&:start)
ch = conn.create_channel
exchange = ch.topic("orders", durable: true)

# 发布：持久化消息 + 发送方确认
exchange.publish(
  { order_id: order.id, event: "paid" }.to_json,
  routing_key: "order.paid",
  persistent: true,
  message_id: SecureRandom.uuid   # 供消费方幂等去重
)

消费侧用 sneakers（基于 bunny 的 worker 框架）。RabbitMQ 的关键概念是 exchange/routing key/queue 三层路由，灵活但概念多；适合「企业内部可靠事件通知」。

3.2 Kafka：吞吐与回放优先

Rails 社区接 Kafka 的标准答案是 Karafka（用法神似 Rails 路由）：

# app/consumers/order_events_consumer.rb
class OrderEventsConsumer < ApplicationConsumer
  def consume
    messages.each do |message|
      event = JSON.parse(message.payload)
      OrderEventHandler.call(event)
    end
  end
end

# karafka.rb —— 声明消费哪个 topic
routes.draw do
  topic "order_events" do
    consumer OrderEventsConsumer
  end
end

发布侧用 WaterDrop（Karafka 配套的 producer）：

WaterDrop::SyncProducer.call(
  { event: "order.paid", order_id: order.id }.to_json,
  topic: "order_events",
  key: order.id.to_s   # 同 key 进同分区 → 同一订单的事件保序
)

Kafka 相比 RabbitMQ 的独特价值：消息可回放（消费位点重置就能重跑历史事件）和分区保序。大数据团队要全量订单事件时，只有 Kafka 这条路合适。

3.3 消费侧的三个生死问题

幂等：MQ 的投递语义是「至少一次」，重复消费是常态不是异常。每个消费者都必须能安全重放：

def call(event)
  # 用 message_id 去重，或用业务唯一键 upsert
  return if ProcessedEvent.exists?(message_id: event["message_id"])
  ActiveRecord::Base.transaction do
    ProcessedEvent.create!(message_id: event["message_id"])
    handle(event)
  end
end

死信：处理失败不能无限重试（一条坏消息卡死整个分区）。重试 N 次后进死信队列，告警 + 人工/延时处理。Karafka 有 Dead Letter Queue 原生支持，RabbitMQ 配 DLX。
发布可靠性：「先写库后发消息」存在窗口期——库写了、进程挂了、消息没发。解法是 Outbox 模式：业务数据和 outbox 事件表在同一个事务里写库，后台进程轮询 outbox 表投递 MQ，投递成功标记已发。数据一致性要求高的链路（钱、库存）必须上 outbox，不能裸发。

第四篇大数据组件：先想清楚 Rails 的角色

标题里最常见的认知偏差是「Rails 怎么接 Spark」。正确的问题其实是：在大数据架构里，Rails 应用应该站在什么位置？ 答案是——Rails 几乎从不「接」Spark，它站在管道的两端：

flowchart LR
    A["Rails 应用<br/>业务数据库 MySQL/PG"] -->|"CDC / 事件 Kafka / 定时导出"| B["数据管道<br/>Kafka"]
    B --> C["计算引擎<br/>Spark / Flink"]
    C --> D["分析存储<br/>ClickHouse / ES / Hive"]
    D -->|"API / 只读库 / 回写"| E["Rails 应用<br/>展示分析结果"]

4.1 上游角色：把数据交出去

Rails 是业务数据的源头，交出去的方式按实时性递增：

定时导出（小时/天级）：find_each 分批读库导 CSV/Parquet 上传对象存储。简单可靠，报表场景够用。注意 find_each 默认按主键分批，千万别在导大表时用 each（全量加载内存爆炸）或 offset 分页（越深越慢）。
Kafka 事件（秒级）：重要业务事件按第三篇的方式发 Kafka，数据团队自己消费。
CDC（准实时、全量变更）：Debezium/Canal 监听 binlog，业务代码零侵入。数据团队的最爱——不用求你在每个 Model 里埋事件。

原则：同一份数据只选一条路，既发 Kafka 又跑 CDC 会造成数据团队收到双份口径。

4.2 下游角色：把结果拿回来

Spark/Flink 算完的结果（用户画像、推荐列表、统计报表），Rails 消费的方式：

读分析库：ClickHouse/ES 直接开只读连接给 Rails（用 establish_connection 配第二数据源），OLAP 查询走它，别打 MySQL。
回写业务库：推荐结果、用户分群这类要参与业务逻辑的，由数据管道回写 MySQL/Redis，Rails 无感知地读——首选方案，耦合最低。
内部 HTTP API：数据团队提供服务接口，Rails 用 Faraday/HTTParty 调。适用跨团队边界，记得按第五篇配超时熔断。

4.3 反模式警告

不要在 Rails 进程里嵌 Spark 客户端跑计算——Ruby 不在 JVM 大数据生态里，硬接只有痛苦。
不要让 Spark 作业直接写 Rails 的在线 MySQL 主库——批量回写打爆主库的事故年年有，回写写从库同步的旁表或走限速的 API。

第五篇通用纪律：接入任何组件前的检查清单

前四篇的教训抽象出来，是一套与具体组件无关的纪律。以后接任何外部服务（HTTP API、对象存储、AI 模型接口都一样），按这张清单过一遍：

5.1 超时：永远不依赖默认值

# HTTP 客户端：连接/读/写三个超时分开设
Faraday.new(url: "https://api.example.com") do |f|
  f.options.timeout = 3        # 读超时
  f.options.open_timeout = 1   # 连接超时必须更短
end

默认超时几乎都是灾难（Ruby 的 Net::HTTP 读超时默认 60s——下游挂了，你的 Puma 线程全部吊死 60 秒，线程池耗尽，全站 500）。所有跨进程调用必须显式设超时，且要比上游网关的超时短。

5.2 重试：只对幂等操作，且带退避

retry_on Net::OpenTimeout, wait: :exponentially_longer, attempts: 5

重试放大故障——下游已经过载，你的重试是在 DDoS 它。规则：GET/幂等操作才可重试；次数有上限；间隔指数退避加抖动。

5.3 熔断：下游持续失败就快速失败

# stoplight gem：失败率超阈值 → 熔断器打开，直接抛错不发起请求
light = Stoplight("es-search") { Post.search(query) }
light.with_fallback { Post.where("title LIKE ?", "%#{query}%").limit(20) }  # 降级：回退 DB 模糊查
                       .run

没有熔断的系统，下游慢 = 全站慢。熔断器的意义是保护自己的线程池，顺带给下游喘息时间。配一个配置中心的降级开关（如 features.es_search = false 时直接走 DB），是大流量系统的标准配置。

5.4 幂等：写操作带唯一键

对外发消息：带 message_id（见第三篇）。
对外调写 API：带 Idempotency-Key header（Stripe 系 API 的标准）。
自己提供写接口：用唯一索引兜底（add_index :payments, :idempotency_key, unique: true），重复请求撞索引返回原结果。

5.5 连接池与背压

每个组件的连接池都要和 Puma 并发模型对齐：Puma 5 workers × 16 threads = 80 并发 → DB/Redis 连接池至少 80 → 而下游服务/数据库能不能扛 80 个长连接，要算。Sidekiq 的并发（默认 5~25）单独算一份。连接数规划错位是生产事故的高发区。

5.6 可观测性：每次外部调用都埋点

# 用 instrument 包裹外部调用，自动记录耗时，可接入 StatsD/Prometheus
ActiveSupport::Notifications.instrument("external.es_search", index: "posts") do
  Post.search(query)
end

加上 SkyWalking/OpenTelemetry 做分布式追踪（Rails 侧 opentelemetry-instrumentation-rails 一行接入），每个外部组件的耗时、错误率、QPS 都要能在监控面板上单独看到——出问题时你才知道是哪个组件在拖。

5.7 生态边界：不是所有中间件都有 Ruby 版

接入任何组件前先问一句：这是本生态的活法吗？ 最典型的例子是 Nacos/Sentinel 这类 Spring Cloud 全家桶——Nacos 官方只维护 Java/Go/Python 客户端，Ruby 没有可用 SDK。这不是生态缺陷，而是因为它们解决的问题在 Rails 世界各有归宿：

服务发现：Nacos 是客户端发现模式（Feign 需要实例列表），Rails 文化是单体优先；即使微服务化，K8s Service DNS / 云 LB 这类服务端发现已把注册中心吃掉了，调用方根本不需要知道实例列表。
配置中心：部署期配置用 ENV + ConfigMap，密钥用 credentials，动态开关用 flipper，业务热配置一张 config 表加短 TTL 缓存就够。
限流降级：Sentinel 没有 Ruby 版，对应物是 Rack::Attack（限流）+ stoplight（熔断）。

如果公司基础设施已经是 Nacos（Rails 服务必须融入），原则是让平台层消化异构，不要在应用里养半成品客户端：优先走 K8s 部署 + 网关适配（Rails 应用完全无感知）；必须注册进 Nacos 时，用 OpenAPI 在启动脚本里注册实例 + 定时心跳（十几行脚本的事），配置拉取同理。SDK 的连接管理、本地缓存、监听重连这些核心行为没有维护好的 Ruby 实现，自己扛就是给自己找事故。

5.8 对象存储：文件别过应用服务器

入门篇 §6.3 讲了 Active Storage 的用法，生产接 S3/OSS 时核心纪律只有一条：文件不经过 Rails 进程。

默认链路是浏览器 → Rails → S3：一个 100MB 上传占住一个 Puma worker 几十秒，几个并发上传就能吃光线程池（入门篇 §8.2 的并发模型在这里兑现成事故）。正确姿势是 Direct Upload：浏览器先向 Rails 申请预签名 URL（Active Storage 自带 /rails/active_storage/direct_uploads 端点），然后直传 S3，表单提交时只带一个 signed_id：

# 视图里一行开启
form.file_field :video, direct_upload: true

配套三件事：

公开资源走 CDN 回源：别让每个头像请求都打到 S3（流量费 + 延迟双输）。
私有文件用短时效签名 URL：rails_blob_url 的链接永久有效且经 Rails 代理；敏感文件用 avatar.url(expires_in: 5.minutes) 直出 S3。
图片变体改异步预热：默认首次访问才懒生成缩略图（慢且占 worker），上传完成后用 Job 预生成（avatar.variant(resize_to_limit: [200, 200]).processed）。

还有两个自动化问题必须回答，否则上线就是给运维埋雷：

垃圾谁来清？不会自动发生，要两道工序。 一是应用侧：浏览器直传成功但用户没提交表单，留下「传了但没关联」的孤儿 blob——Rails 不自动清，挂周期任务扫：

ActiveStorage::Blob.unattached.where("created_at < ?", 2.days.ago).find_each(&:purge_later)

二是存储侧：分片上传（multipart）中断会在 S3 留下残片，S3 对残片照常收费——bucket 上必须配 Lifecycle 规则 AbortIncompleteMultipartUpload（如 7 天后中止），不配就是漏水的账单。

传完后怎么触发后续处理？有现成挂点。 blob 关联到记录时，Active Storage 自动排 AnalyzeJob 提取元数据（宽高、时长、校验和），这是内置的「消息」；业务级处理（转码、扫毒、抽帧）挂在自己模型的回调上：

class Video < ApplicationRecord
  has_one_attached :file
  after_save_commit :enqueue_transcode, if: -> { file.attached? }

  private

  def enqueue_transcode
    TranscodeJob.perform_later(id)   # 走 §6.1 的 Active Job 链路，别在请求里做
  end
end

只有绕过 Active Storage 直接对接桶事件的大文件管道，才需要 S3 Event Notification → SQS → 消费者的路子——那是第三篇 MQ 的地盘，一般项目用不上。

收尾：集成的本质是边界管理

回头看这五篇，真正难的技术点一个都没有——gem 都现成，文档都齐全。难的是边界上的纪律：数据跨进程之后，一致性、时序、失败语义全都变了。最后三条心法：

每接一个组件，先写「它挂了怎么办」。缓存挂了降级、ES 挂了回 DB、MQ 挂了走 outbox 堆积——降级路径没设计的集成，等于给系统埋雷。
数据流向永远是单向的。业务库 → 搜索/分析/缓存，反向只读不写。双向同步的系统没有一个不出数据事故的。
组件越少越好。每接一个组件都要回答「现有组件真的解决不了吗」。SQLite 能扛的缓存别上 Redis，Sidekiq 能扛的异步别上 Kafka——架构的复杂度成本是持续的运维和认知负担，不是一次性接入。

至此，从入门篇的「一个人写一个应用」，到这一篇的「让应用成为系统版图里可靠的一环」，Rails 工程师的完整拼图就齐了。

架构 on 方糖猫Blog

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

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

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

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

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

四层排序漏斗总览

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

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

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

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

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

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

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

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

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

和关注流的关系

落地清单

Ruby on Rails 高级篇：接入 Redis、Elasticsearch、消息队列与大数据组件的工程实践

Ruby on Rails 高级篇：接入 Redis、Elasticsearch、消息队列与大数据组件的工程实践

第一篇 Redis：一个组件，四种角色

1.1 角色一：缓存（最常用）

1.2 角色二：Sidekiq 任务队列

1.3 角色三：Action Cable 实时推送

1.4 角色四：业务数据结构

1.5 追问：有没有 JetCache 那种「本地 + Redis」两级缓存？

第二篇 Elasticsearch：搜索是数据同步问题

2.1 Gem 选型

2.2 索引同步：三种策略的取舍

2.3 零停机重建索引

2.4 生产上死在哪

第三篇 消息队列：ActiveJob 不是 MQ

3.1 RabbitMQ：可靠投递优先

3.2 Kafka：吞吐与回放优先

3.3 消费侧的三个生死问题

第四篇 大数据组件：先想清楚 Rails 的角色

4.1 上游角色：把数据交出去

4.2 下游角色：把结果拿回来

4.3 反模式警告

第五篇 通用纪律：接入任何组件前的检查清单

5.1 超时：永远不依赖默认值

5.2 重试：只对幂等操作，且带退避

5.3 熔断：下游持续失败就快速失败

5.4 幂等：写操作带唯一键

5.5 连接池与背压

5.6 可观测性：每次外部调用都埋点

5.7 生态边界：不是所有中间件都有 Ruby 版

5.8 对象存储：文件别过应用服务器

收尾：集成的本质是边界管理

第三篇消息队列：ActiveJob 不是 MQ

第四篇大数据组件：先想清楚 Rails 的角色

第五篇通用纪律：接入任何组件前的检查清单