微博推荐引擎架构蜕变之路
- 9. 推荐引擎具体分析
? 质量 – 不稳定的核心原因，工作量巨大
? 工具 – 有简单的建设但很不足，公司内部有一些通用工具可用
? 运维人力 – 需要专业的运维团队支援
? 改造人力 – 引擎团队不足十人，需要协调人力支援
- 10. 改造实践
? 初期 – 利用现有工具控制局面
? 中期 – 汇聚人力，提升质量
物料存储
已读
? 后期 – 优化工具
扩缩容
? 其他
- 12. 质量改造 – 物料
问题分析
? 引擎单机存储所有物料及其特征
? 特征数量数百，整体数据较稀疏，大量字符串
? 支持千万级别物料的能力（内存效率 & 更新速度）
? 原有基于mmap的存储引擎速度慢且存在内存泄漏
方案
? 简单的单机模式，快速的加载
? 连续内存对象，2级索引
- 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与承载能力选
择降级比例
? 热点应对机制，基于规则与人工的大比例扩容
