面试哥最近在研究各个大厂的技术架构，看到了知乎的一份平台架构pdf写了个脚本导出为图片格式，平时我也是知乎的重度用户，分享给大家。
以下为正文：
以下为文字版本：
-
. 知乎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: Efficiency, 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.
评论区