Twitter推荐引擎架构设计分析

0 前言

可靠性保障是复杂的系统工程，尤其可靠性已异常的线上服务，在业务迭代、成本约束、人力投入等方面的约束下 ，提升可用性就不再纯技术问题。

推荐引擎作为各类推荐业务在线服务的枢纽环节支持推特热门流、小视频后推荐等业务，快速迭代时，可靠性问题逐渐暴露。随业务需求变化，物料规模、已读过滤等逐渐成为限制迭代的瓶颈点。频发的抖动与宕机，快速膨胀代码量，极大消耗开发精力。多重压力下，推荐引擎滑向失控边缘。

研发中心基础架构部架构师分享推特推荐引擎在数月的时间里从不可控回到可控，可用性由不足2 个9提升至3个9，同时提升业务支持能力的经验，帮你系统性解决可靠性问题。

1 推荐引擎架构

推特推荐引擎服务于推特各类推荐业务，如服务热门流、热点流、视频后推荐等，是推荐系统的枢纽，需结合特征、模型、物料等环节驱动业务运行，架构图：

用户请求推荐内容时，先到达推荐前端，随后在总控开启推荐流程：

• 总控会获取本次刷新相关的信息，如用户兴趣、引流推特特征、已读信息等
• 总控将相关信息输入召回引擎，召回引擎根据这些信息获得备选推特 ID。召回分为：
  • 标签召回，即根据用户信息、热点业务规则进行排序
  • 模型召回，即变换数据形式，用向量的方式通过本地或远程模型服务获取物料
• 获取备选 ID 后，排序引擎先补充相关特征信息将备选 ID 构造成完整物料，通过 Hash 等方式将之转化为可供排序模型使用的特征向量，送到排序模型打分，完成排序
• 总控在插入广告后通过前端填充内容，完成推荐

训练将接收引擎及客户端用户行为日志，实时更新排序、召回模型；物料将实时更新物料库，将特征的更新总结为物料包流和更新流，供引擎实时更新和加载。

2 推荐引擎可靠性挑战

推特推荐引擎快速迭代中暴露的问题主要是：稳定性和。

2.1 稳定性

表现为单台引擎（如前文排序引擎）工作几个小时后即会发生一次宕机、内存溢出、超时启停等问题。如有突发流量更疲于应对。此外，当时物料规模、已读存储能力等方面的设计已无法满足现在业务需求。

2.2 业务支持

改造系统比打造新系统更难，不仅需要梳理数 10 万行代码，同时改造中系统还在迭代不能下线，再加上团队人力不足，外部的压力（如公司对成本、机器利用率等的要求）等，该问题已经超越技术问题。

3 系统可靠运行的因素

质量

• 架构
• 代码质量

工具：

• 治理
• 扩缩容

人力：

• 运维
• 监控

在线系统稳定运行依赖于三个方面：系统本身架构设计和代码的质量；自动化的工具（如扩缩容、异常治理等）；运维、监控人员人力。三方面如木桶，有一个长板即可支持较大流量：若系统健壮则运行时必然问题较少或若运维人力足沛也可解决多数问题。

多数公司难100%保证某一长板，需结合公司具体情况保证基本质量，出现错误时多数依靠工具解决，少数依靠运维人员。对当时的推特推荐引擎，质量是核心问题，但投入大、见效慢；虽有如异常处置等简单工具建设，但组织简单且互有冲突，甚至无扩缩容工具，开发空间大，只需适配推特内部成熟工具体系，即可乘高决水，事半功倍；也急需从0到1引入运维团队。

4 改造实践

推特推荐引擎改造分为三阶段：

• 通过工具建设先稳住系统，保障后期改造的精力
• 集中人力大量重写核心环节，提升系统质量
• 再次优化工具建设，降低维护稳定所需人力

来看：物料存储结构改造、已读服务改造和扩缩容工具。

初始阶段，我们接入了推特成熟的运维工具，组合了原有自动处置工具、优化了上线脚本，实现了基于 QPS 和超时率的简单自动缩扩容功能。

4.1 质量改造-物料

排序引擎运行的第一步为将物料初始化为带特征的物料，一次需处理数万条数据，原物料携带特征多，一次请求所需信息量大，因此选择单机存储所有物料。

存储原使用基于内存映射的外部存储引擎。该引擎沟通速度慢，沟通占用大，有内存性能问题（推特推荐引擎的核心问题所在），限制物料规模。因此重写该引擎，考虑到：

• 单条物料存储
• 整体物料存储

物料的特征：特征数量数百但平均填充率较低，整体数据较稀疏，大量特征为字符串型。若用类实现则稀疏数据造成内存浪费，大量字符串造成内存碎片，长期使用无法保证稳定性。因此物料结构设计需满足：

• 内存需连续不可有碎片
• 稀疏情况下空间的节约
• 不可影响系统性能

实现如下图的二级索引结构：

如图将物料分成了四段：

• 白色为头部，保存基本信息
• 红色为一级索引
• 黄色为二级索引
• 绿色为实际数据段

该结构一级索引为 Bitmap，每一位均可表示是否有一个字段存在物料中，实现了稀疏的支持。二级索引为所有存在字段的偏移量位置：

• 对字符串为编译量
• 对数字或浮点数存储数据本身，保证了存储速度
• 该存储结构内存连续

满足了上述三条要求。整体物料存储用Concurrent HashMap结构，更新速度可达数万/s，满足物料数量要求。

4.2 质量改造-已读

已读功能，推荐流程的核心环节，推荐系统需要依赖用户已读数据，将用户未读内容排序。推特推荐系统原已读是基于 bloom filter 实现。

如图为推特原 30 天已读方案实例：共四个 filter，每十天存储一个 filter，每次读取覆盖最近 30 天的四个 filter，取回 bloom filter 后通过或运算将其合并成一个 bloom filter 供后续业务使用。

该方案：

• 结构不合理，面对所有用户 bloom filter 大小均不变，因此：高消费的用户使用推特频率高，填充率高，则误判高；低消费用户阅读量小，空间利用率低，浪费资源
• 直接读取存储的 Redis，存储一旦出错服务也难免受牵连，稳定性差
• 各业务直接读取资源本身，判断逻辑需各服务独立实现

因此改造：

• 以读独立成为一个服务，各个业务调取服务而非缓存；将常用判断逻辑封装为 SDK，便于业务改动
• 存储方式保持 bloom filter，但串的长度和单位大小均可变。在写入时不按照固定时长写入，而是前一个 filter 填充率达到阈值时才开启一个新的 bloom filter，根据前一个 filter 填充速度选择下一个 filter 的大小。如此可安全节省原来一半以上的空间：高消费用户 bloom filter 串虽较长，但体积也会较大，可减少误判；超高消费用户限制最大串长度，已读记录时长虽会缩短，但是能保证其已读内容相对长久；低消费用户可用较小的 bloom filter 完成已读记录
• 稳定性，一方面建立独立的短期（如几个小时）已读存储，在主要资源不可用时提供降级服务；另一方面，优化 Redis 资源访问方式，Meta 信息及最新一个 bloom fileter 需从主库读取，保证信息时效性，已不更新的其他信息读取从库即可，可缓解 Redis 的存储资源

4.3 外部工具-扩缩容

应对问题：

• 日常流量波动，如业务高峰期，自动扩容应对流量高峰
• 热点事件突发流量，需基于冗余度的自动扩缩容和热点应对机制

突发流量特征：

红线流量，绿线系统承稳能力（机器数量），绿线在红线之上方可保证系统正常运行。绿线高于红线部分为冗余度。

流量t1来，红线速升，t2超过绿线，扩容系统在 t1 后某点发现流量，触发扩容，最终机器在t3到位。

实现该突发流量扩容需做到：

• t1~t2快速发现流量到来，如此时还未做处理，到 t2 后便已超时
• 建立降级策略以供扩容时暂用，如停止某些次要功能、减少推荐处理条数
• 减少扩容时间（即 t1 到 t3 的时间），优化程序启动速度

具体问题可根据历史流量数据和公司情况处理：如公司成本压力小可将冗余度调高，将绿线整体上移；如服务自身启动快，可省略降级策略。

推特推荐引擎依赖已有成熟扩容基础设施，解决流量快速发现问题；结合物料改造，引擎启动速度从20min提高至5min。

推特推荐引擎在各环节均加入计算量条数和请求的动态降级能力，根据当前实际 QPS 与承载能力选择降级比例。如当前可处理计算量条数的 80%，如果流量增加则只处理 70%。自动机制之外，如有热点事件预警可全公司提前动员，每日 push 场景可提前处理。

5 总结

灵活的工具可提高开发效率。接入推特现有工具体系时，先做个可手动查看效果及接管自动扩容逻辑的界面，提高掌控系统的速度。利用大数据类分析工具，可通过录制大量请求、查看其UID或某些特症等分析异常请求原因。

本次改造中大量工作为梳理旧业务代码，繁琐无聊，团队士气也重要。推荐改造项目共历时三个月，正确处理请求比例从不到 99%提升至 99.9%以上，服务耗时降低 25%，不增加资源支持单机 500 万-1000 万物料，启动速度提升至原先的 4 倍。