知乎 feed 流架构演进_架构师峰会_北京站.pptx

知乎Feed流架构演进 2013 年加⼊知乎，知乎 Feed 流技术负责⼈，负责期间 Server 端 P95 响应时间从 1.6S 降低到 700Ms，稳定性由 99.9% 提升到 99.995% 姚钢强 A. Feed 流的需求和特点 B. ⽼ Feed 流的构架遇到的问题 C. 新构架 Redis module 技术⽅案 D. Redis module ⽅案遇到的问题 E. 新的问题与挑战 提纲 A. DAU 2600万 (2017.9) B. 个性化推荐，每次请求返回内容不同(与搜索不同， cache 难做) C. ⽤户动态准实时分发 知乎 Feed 流的需求和特点 ⽆个性化(热⻔榜单) 用户个性化 push A. 资源消耗严重，计算量⼤，存储量⼤ B. 智能推荐，排序难以实时调整 C. 过滤⽐较难做(关注 or 被删除) D. 动态准实时分发难以达到 (⾼粉丝⽤户) push 存在的问题 实时 pull client pull 计算流程(慢) member 推荐的相关源 过滤条⽬ 从指定的源拉取条⽬ 拼装 meta 选前 10 条 算法排序 Y N 提前计算，做缓存 从指定的源拉取条⽬ member 相关的源 后 10 条 缓存 拼装 meta 选前 20 条 client 算法排序 过滤条⽬ 前 10 条 Y N • 存在冗余计算，占⽤资源多 • 冷启动 P95 响应时间⻓ • ⽤户⾏为分发延迟，体验差 • 离线计算策略复杂，难以维护 • 推荐算法难以实时调整 提前计算的问题 • 依赖服务响应慢 • redis cache + local cache • gevent 并发 • 超时做降级 • Python 计算太慢 • Cython 模块替换 • 由于条⽬不够，反复访问底层源的存储 feesource 如何优化，难点⼉在哪⼉？ • 拉取出更多的条⽬，防⽌被过滤掉？ • 拉取更多的条⽬也会浪费时间，过滤压⼒⼤ • 根据算法拉取出更精准的条⽬？ • 算法期望召回池越⼤越好 可能的解决方案 计算下推，接近存储 新 feed 计算逻辑 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. Redis Module • 加载定制命令(MODULE LOAD module load lib_path/xx.so) • 执⾏定制命令 • 卸载定制命令(MODULE UNLOAD mymodule) Redis Module redisServer + modules: dict + commands: dict operations RedisModule_Init 初始化模块 ... RedisModule_CreateCommand 注册定制命令 handle = dlopen(lib_path/XX.so) dlsym(handle,RedisModule_OnLoad) Client module load lib_path/xx.so 加载定制命令 RedisModule_CreateCommand 注册定制命令 START END attributes redisServer attributes + modules: dict + commands: dict operations 模块 callback moduleHandlePropagationAfterCommandCallback 查找命令 RedisModuleCommandDispatcher 执行定制命令 回收内存 moduleFreeContext 执⾏命令 START END 清空注册符号 dictDelete(mands,cmdname) 卸载模块 moduleFreeModuleStructure redisServer attribute