qconf

1. 微博推荐引擎
架构蜕变之路
马骎

3. 自我介绍-马骎
• 17年加入微博
关系流与互动等业务
AB测试系统
• 20年9月起负责推荐引擎
系统改造

4. 概要
• 微博推荐引擎介绍
• 在线业务可靠性保障的条件
• 微博推荐引擎改造实践
• 总结回顾

5. 微博推荐引擎介绍
• 服务热门流，热点流，视频后推荐等
• 推荐系统的枢纽
• 架构：总控 + 召回引擎 + 排序引擎

6. 引擎架构
推荐前端
总控
召回引擎 排序引擎
排序模型
召回模型
训练 物料库
在线物料构造
特征 / 实验 / 广告 …

7. 推荐引擎可靠性挑战
• 频繁宕机，正确返回不足两个9
• 代码数十万行
• 物料规模 （百万级 à 千万级）
• 突发流量
• 成本约束，人力不足
可靠性改造不只是技术问题

8. 系统可靠运行的因素
质量
• 架构
• 代码质量
• …
工具
• 治理
• 扩缩容
• …
人力
• 运维
• 监控
• …

9. 推荐引擎具体分析
• 质量 – 不稳定的核心原因，工作量巨大
• 工具 – 有简单的建设但很不足，公司内部有一些通用工具可用
• 运维人力 – 需要专业的运维团队支援
• 改造人力 – 引擎团队不足十人，需要协调人力支援

10. 改造实践
• 初期 – 利用现有工具控制局面
• 中期 – 汇聚人力，提升质量
物料存储
已读
• 后期 – 优化工具
扩缩容
• 其他

11. 运维系统接入
初始状态
• 手动运维与上线，大量的超时与宕机，一名开发同学时间用于上线等运维操作
应对
• 自动化运维工具接入，优化上线脚本
• 基于QPS和超时率的简单自动扩缩容功能
• 组合原有自动处置工具

12. 质量改造 – 物料
问题分析
• 引擎单机存储所有物料及其特征
• 特征数量数百，整体数据较稀疏，大量字符串
• 支持千万级别物料的能力（内存效率 & 更新速度）
• 原有基于mmap的存储引擎速度慢且存在内存泄漏
方案
• 简单的单机模式，快速的加载
• 连续内存对象，2级索引

13. 质量改造 – 物料

14. 质量改造 – 已读
问题分析
• 一个早期实现的基于bloom filter的方案
• 固定size，低消费用户空间利用率低，高消费用户错误率高
• or 操作造成的四倍空间浪费
• 资源出现问题时无应对方法
• 判断逻辑在各服务需要各自实现 BF 1-10 BF 11-20 BF 21-30 BF 31-40
BF 1-10 BF 11-20 BF 21-30 BF 31-40 BF 41-50
Day 31-40
Day 41-50
Read or
Read or
Write
Write

15. 质量改造 – 已读
方案
• 独立成为一个服务，将常用的判断逻辑封装为SDK
• 一串长度可变的bloom filter，限制最大长度
• 前一个填充率达到阈值时开启新的一个bloom filter
• 根据前一个填充速度选择下一个的大小
• Meta信息及最后一个bloom filter需要从主库读取，其他读从库
• 一个独立的短期已读存储，在主要资源不可用时提供降级的服务

16. 外部工具 – 扩缩容
• 日常流量 - 午高峰晚高峰的自动扩容
• 突发流量 - 基于冗余度的自动扩缩容，热点应对机制

17. 外部工具 – 扩缩容
• 突发流量自动扩缩容问题分析
• 快速发现 à 更快的数据通道
• 降级策略 à 不能急速启动且日常冗余度没有非常高时
• 快速扩容 à 更快的机器创建，更快的服务启动
• 冗余度 à 更多的时间
t1 t2 t3
冗余
降级

18. 外部工具 – 扩缩容
• 推荐引擎启动速度 20min à 5min
• 各环节均加入计算量（条数 & 请求）降级，根据当前实际QPS与承载能力选
择降级比例
• 热点应对机制，基于规则与人工的大比例扩容

19. 灵活的工作方法
• 丰富的技能 & 灵活的工具
• 例1：快速开发自动扩缩容工具
• 例2：利用数据工具快速分析条数异常请求的原因

20. 沟通
• 其他团队及部门的支持
• 内部工作的合理安排

21. 总结
• 20.12-21.03 三个多月的时间完成了主要的改造工作，正确处理请求的比例提
升到99.9%以上，服务耗时降低25%，不增加资源支持单机500万物料，启动
速度提升至原先的4倍。

22. 问答