小白入门
这一页先建立直觉,再给你三张图:架构图画「房子怎么分」,流程图画「事情按什么顺序缩小」,时序图画「谁先说话、谁后回话」。后面每一章都按这个习惯配图。
三种图怎么看
| 图的种类 | 看它干什么 | 本页例子 |
|---|---|---|
| 架构图 | 房子怎么隔间:谁和谁挨着、哪条路不能共用 | 三条路、单元化、七层 |
| 流程图 | 事情怎么一步步变少或选路 | 推荐漏斗、选存储、降级 |
| 时序图 | 谁先打电话、谁后回电,中间会不会等 | 一次上滑、评论跨城、模型更新 |
三条路,不要画成一条
你在手机上滑一下,背后其实同时走三条路。把它们拧成一条,系统一定卡。
- 问菜单(同步 API):「下一批放哪十条?」答案是一份很小的清单:视频 ID、封面、播放地址。必须在大约一眨眼(百毫秒)内回来。
- 上菜(媒体 CDN):真正的视频文件很大,走就近的仓库,不走菜单服务员那条小路。
- 写小票(异步日志):你划走、看完、点赞,事后扔进信箱。用来更新「你爱吃什么」,绝不能让下一道菜等这张小票盖章。
用户上滑
同步路:问菜单
推荐算出下一批 ID
媒体路:上菜
播放器出画面
异步路:写小票
特征与模型更新
为什么要拆成很多厨房
客户端按 UserID 选路
单元 · 北京
Feed / 画像 / 计数
本单元用户数据
单元 · 上海
Feed / 画像 / 计数
本单元用户数据
单元之间异步复制,同一用户不要两边同时写
技术名字叫单元化:按 UserID 把人和数据切开。北京—上海来回大约 40 毫秒,推荐只有大约 100 毫秒预算,跨城炒这道菜很容易超时。细节见单元化。
上滑一次,谁先说话
用户
播放器
网关
Feed 编排
召回排序
CDN
上滑
▶
本地还有缓冲吗
▶
缓冲不足:要下一批
▶
鉴权并纠偏到本单元
▶
并行召回加排序
▶
约十条 meta
◀
ID / 封面 / 播放地址
◀
拉当前和下一条视频
▶
媒体流
◀
出画
◀
异步上报划走或完播
▶
逐步拆时间预算,见一次 Feed 请求。
推荐为什么像漏斗
亿级可推内容池
多路召回 · 千级
粗排 · 百级
精排 · 几十
重排混排 · 约十条
客户端 Feed
漏斗每一层用什么索引,见多阶段漏斗。
划走之后发生了什么
你以为「划走」只是换下一条。对系统来说,这是一张明信片:不喜欢。高峰期一秒钟几千万张明信片,不能让上菜窗口一张张盖章。先扔进大邮箱,流水线在后面分拣。
用户
App
BMQ
Flink
特征 KV
Monolith
划走
▶
上报事件
▶
消费
▶
更新短窗特征
▶
样本
▶
更新 embedding
▶
下次 Feed 就能用上
术语对照(先记这些就够)
| 你会听到 | 小白说法 | 去哪一页 |
|---|---|---|
| Feed / 推荐 | 下一盘菜是什么 | 一次 Feed 请求 |
| 单元化 | 每个城市有完整厨房 | 单元化 |
| 召回 / 粗排 / 精排 | 先抓筐、再过眼、再细打分 | 多阶段漏斗 |
| 特征 | 猜你会不会看完的小卡片 | 特征平台 |
| Monolith / embedding | 每个用户和视频的活页名片 | Monolith |
| Abase / Redis | 记小本本的柜子 | 存储矩阵 |
| ByteGraph | 谁关注谁的族谱 | 存储矩阵 |
| BMQ / Kafka | 扔明信片的大邮箱 | 实时数据平面 |
| CDN / 转码 | 就近影碟店和洗胶卷工厂 | 点播与 CDN |
| 降级 | 先关霓虹灯,保证大门还能进 | 热点与降级 |
看完这一页去哪
地图看七层架构(还有一张穿过七层的时序图)。想对上 Kitex、Abase 这些名字,看技术栈。后面每一页顶部都有黄色的「小白讲解」,下面再跟工程细节。