知乎feed流架构演进

1. 知乎Feed流架构演进

2.

3.

4.

5. 姚钢强 2013 年年加⼊入知乎，知乎 Feed 流技术负责⼈人，负责期间 Server 端 P95 响应时间从 1.6S 降低到 700Ms，稳定性由 99.9% 提升到 99.995%

6. 提纲 A. Feed 流的需求和特点 B. ⽼老老 Feed 流的构架遇到的问题 C. 新构架 Redis module 技术⽅方案 D. Redis module ⽅方案遇到的问题 E. 新的问题与挑战

7. 知乎 Feed 流的需求和特点 A. DAU 2600万（2017.9） B. 个性化推荐，每次请求返回内容不不同（与搜索不不同， cache 难做） C. ⽤用户动态准实时分发

8. ⽆无个性化（热⻔门榜单）

9. ⽤用户个性化 p u s h

10. push 存在的问题 A. 资源消耗严重，计算量量⼤大，存储量量⼤大 B. 智能推荐，排序难以实时调整 C. 过滤⽐比较难做（关注 or 被删除） D. 动态准实时分发难以达到（⾼高粉丝⽤用户）

11. 实时 pull

12. pull 计算流程（慢） client member 推荐的相关源拼装 meta 从指定的源拉取条⽬目 N 选前 10 条过滤条⽬目条⽬目够⽤用 Y 算法排序

13. 提前计算，做缓存 client member 相关的源 N 缓存从指定的源拉取条⽬目 Y 拼装 meta 前 10 条后 10 条缓存 N 选前 20 条过滤条⽬目条⽬目够⽤用 Y 算法排序

14. 提前计算的问题 • 存在冗余计算，占⽤用资源多 • 冷启动 P95 响应时间⻓长 • ⽤用户⾏行行为分发延迟，体验差 • 离线计算策略略复杂，难以维护 • 推荐算法难以实时调整

15. 如何优化，难点⼉儿在哪⼉儿？ • 依赖服务响应慢 • • gevent 并发 • • redis cache + local cache 超时做降级 Python 计算太慢 • • Cython 模块替换由于条⽬目不不够，反复访问底层源的存储 feesource

16. 可能的解决⽅方案 • 拉取出更更多的条⽬目，防⽌止被过滤掉？ • • 拉取更更多的条⽬目也会浪费时间，过滤压⼒力力⼤大根据算法拉取出更更精准的条⽬目？ • 算法期望召回池越⼤大越好

17. 计算下推，接近存储

18. 新 feed 计算逻辑

19. Redis Module Redis modules make possible to extend Redis functionality using external modules, implementing new Redis commands at a speed and with features similar to what can be done inside the core itself.

20. Redis Module • 加载定制命令（MODULE LOAD module load lib_path/xx.so） • 执⾏行行定制命令 • 卸载定制命令（MODULE UNLOAD mymodule）

21. 加载定制命令 Client module load lib_path/xx.so START handle = dlopen("lib_path/XX.so") dlsym(handle,"RedisModule_OnLoad") RedisModule_Init 初始化模块 RedisModule_CreateCommand 注册定制命令 ... RedisModule_CreateCommand 注册定制命令 END redisServer attributes + modules: dict + commands: dict operations

22. 执⾏行行定制命令 Client AxxCmd argv1 argv2 … START 查找命令 RedisModuleCommandDispatcher 执⾏行行命令模块 callback moduleHandlePropagationAfterCommandCallback 回收内存 moduleFreeContext END redisServer attributes + modules: dict + commands: dict operations

23. 卸载定制命令 Client module unload ModuleName START 清空注册符号 dictDelete(server.commands,cmdname) dlclose redisServer attributes + modules: dict + commands: dict operations 卸载模块 moduleFreeModuleStructure END

24. 定制的命令 • open_core, close_core • • Redis module 更更新时打开 core dump，如果 crash ⽅方便便分析 ts_query • Redis 内部的过滤，归并流程

25. t s _ q u e r y 接⼝口设计 • Request • • black_items: 需要过滤的⿊黑名单条⽬目 • merge_strategy: 合并策略略 • • [source_type, source_id]: 需要拉取 source required_number: 需要返回的条⽬目数量量 Response • [item_type, item_id, item_action, item_score]: 返回需要数⽬目的 feed 条⽬目

26. 带来的收益 • 响应时间 P95 降低 300ms • 去掉了了离线计算，节省 60% 的计算资源 • 内容候选池更更⼤大，为算法提供了了更更⼤大的空间 • ⽤用户动态实时分发，算法实时调整

27. 遇到的问题 • Module 更更新不不⽣生效，继续调⽤用⽼老老 Module • Redis 单线程 CPU 瓶颈，⾼高可⽤用 • Redis 的内存浪费

28. M o d u l e 更更新不不⽣生效 • 加载新的 so 后，发现调⽤用的还是⽼老老逻辑 • • GDB 发现存在符号被标记 DF_1_NODELETE dlcose 仅仅声明 so 不不在被系统使⽤用，so 内存占⽤用依旧存在 • gcc 编译使⽤用 STB_GNU_UNIQUE ，防⽌止符号被标记为 DF_1_NODELETE • 按照依赖路路径加载 so，不不直接加载定制的 so

29. R e d i s 单线程 C P U 瓶颈，⾼高可⽤用 • 采⽤用 Redis Sentinel 部署集群，保证⾼高可⽤用 • ⼀一致性哈希 Redis shard，每个 shard 采⽤用 master slave 的⽅方式部署

30. Redis 内存浪费 • 采⽤用 protobuf 和 Redis ziplist 数据压缩，减少 shard • 有多个 slave ，还是浪费内存，没有根本解决问题 • Redis 仅仅作为任务队列列，任务分派给其他进程处理理？ • 同⼀一台机器器伴随 Redis 部署计算节点？

31. Feed 架构的历程 • Feed 都⼀一样 • Feed 个性化，推模型 • Feed 个性化，拉模型 + 离线计算 • Feed 个性化，拉模型，采⽤用 Redis Module，计算接近存储

32. 参考资料料 • Serving Facebook Multifeed: Efﬁciency, performance gains through redesign • dlclose - close a symbol table handle • dlclose doesn't really unload shared object, no matter how many times it is called • Redis Modules: an introduction to the API • Redis Loadable Modules System

33.