learntoall

小白入门

这一页先建立直觉,再给你三张图:架构图画「房子怎么分」,流程图画「事情按什么顺序缩小」,时序图画「谁先说话、谁后回话」。后面每一章都按这个习惯配图。

三种图怎么看

图的种类看它干什么本页例子
架构图房子怎么隔间:谁和谁挨着、哪条路不能共用三条路、单元化、七层
流程图事情怎么一步步变少或选路推荐漏斗、选存储、降级
时序图谁先打电话、谁后回电,中间会不会等一次上滑、评论跨城、模型更新

三条路,不要画成一条

你在手机上滑一下,背后其实同时走三条路。把它们拧成一条,系统一定卡。

  1. 问菜单(同步 API):「下一批放哪十条?」答案是一份很小的清单:视频 ID、封面、播放地址。必须在大约一眨眼(百毫秒)内回来。
  2. 上菜(媒体 CDN):真正的视频文件很大,走就近的仓库,不走菜单服务员那条小路。
  3. 写小票(异步日志):你划走、看完、点赞,事后扔进信箱。用来更新「你爱吃什么」,绝不能让下一道菜等这张小票盖章。
用户上滑
同步路:问菜单
推荐算出下一批 ID
媒体路:上菜
播放器出画面
异步路:写小票
特征与模型更新
架构图 · 一次上滑拆成三条路:问菜单、上菜、写小票

为什么要拆成很多厨房

客户端按 UserID 选路

单元 · 北京

Feed / 画像 / 计数
本单元用户数据

单元 · 上海

Feed / 画像 / 计数
本单元用户数据

单元之间异步复制,同一用户不要两边同时写

架构图 · 单元化:用户被分到不同城市厨房,单元内尽量自己完成

技术名字叫单元化:按 UserID 把人和数据切开。北京—上海来回大约 40 毫秒,推荐只有大约 100 毫秒预算,跨城炒这道菜很容易超时。细节见单元化

上滑一次,谁先说话

用户
播放器
网关
Feed 编排
召回排序
CDN

上滑

本地还有缓冲吗

缓冲不足:要下一批

鉴权并纠偏到本单元

并行召回加排序

约十条 meta

ID / 封面 / 播放地址

拉当前和下一条视频

媒体流

出画

异步上报划走或完播

时序图 · 本地缓冲不足才打 Feed,播放走 CDN,行为事后上报

逐步拆时间预算,见一次 Feed 请求

推荐为什么像漏斗

亿级可推内容池
多路召回 · 千级
粗排 · 百级
精排 · 几十
重排混排 · 约十条
客户端 Feed
流程图 · 推荐漏斗:从亿级库存收到约十条 Feed

漏斗每一层用什么索引,见多阶段漏斗

划走之后发生了什么

你以为「划走」只是换下一条。对系统来说,这是一张明信片:不喜欢。高峰期一秒钟几千万张明信片,不能让上菜窗口一张张盖章。先扔进大邮箱,流水线在后面分拣。

用户
App
BMQ
Flink
特征 KV
Monolith

划走

上报事件

消费

更新短窗特征

样本

更新 embedding

下次 Feed 就能用上
时序图 · 划走进队列,特征和模型异步更新,下次 Feed 再用

术语对照(先记这些就够)

你会听到小白说法去哪一页
Feed / 推荐下一盘菜是什么一次 Feed 请求
单元化每个城市有完整厨房单元化
召回 / 粗排 / 精排先抓筐、再过眼、再细打分多阶段漏斗
特征猜你会不会看完的小卡片特征平台
Monolith / embedding每个用户和视频的活页名片Monolith
Abase / Redis记小本本的柜子存储矩阵
ByteGraph谁关注谁的族谱存储矩阵
BMQ / Kafka扔明信片的大邮箱实时数据平面
CDN / 转码就近影碟店和洗胶卷工厂点播与 CDN
降级先关霓虹灯,保证大门还能进热点与降级

看完这一页去哪

地图看七层架构(还有一张穿过七层的时序图)。想对上 Kitex、Abase 这些名字,看技术栈。后面每一页顶部都有黄色的「小白讲解」,下面再跟工程细节。