MyBilibili 面试话术
一句话概括
"架构设计采用 Go 胖二进制 + 本地 SQLite 缓存 + PG 归档 + Redis 写缓冲的混合方案。读走本地 mmap，~0.01ms，扛 99% 请求；写走 Redis，异步刷 PG，~0.5ms 返回。支持从小到一台盒子到大到一百台机器的水平扩展，不换架构不改代码。部署在自有设备上，月费 100 元电费，同等云配置约 20000 元/月。"
面试官可能问的
| 问题 | 回答 |
|---|
| 为什么不用 ES？ | PG tsvector 全文检索够用，不需要 ES 的重量 |
| 为什么不用 MongoDB？ | PG JSONB 功能一样，省一个组件 |
| 数据一致性怎么保证？ | 强一致走 PG 事务，最终一致走 Redis → PG |
| SQLite 写入瓶颈怎么办？ | SQLite 只做只读缓存，写走 Redis → PG |
| 水平扩展怎么做？ | Traefik 路由 + 粘性策略，加实例就行 |
| 盒子硬件太弱怎么办？ | 业务无状态，扩到其他盒子或手机 |
| PG 挂了怎么办？ | 读走 SQLite 本地缓存，写暂存 Redis，恢复后同步 |
与传统架构对比
| 你的方案 | 传统方案 | 面试官评价 |
|---|
| 每个组件讲得出为什么选它 | 别人用我也用 | 有深度，不是照着教程搭 |
| 知道每个组件的边界和局限 | 以为 ES 是万能的 | 有实战经验 |
| 能讲清楚取舍和成本 | 只讲功能不讲成本 | 有架构思维 |
| 从性能到成本到运维全链路 | 只关心功能实现 | 有全局视野 |
技术亮点
- PG 一库三用：关系表 + JSONB 文档 + 全文检索，替代 MySQL + MongoDB + ES
- SQLite 本地缓存：mmap 零拷贝，~0.01ms，扛 99% 读流量
- Redis 写缓冲：先写 Redis 再异步刷 PG，用户感知 ~0.5ms
- 粘性路由：按资源 × 用户 × 地点调度，资源利用率最大化
- 峰谷动态调整：凌晨缩实例省资源，晚高峰扩实例扛流量
- 从小到一台盒子到大到一百台机器，不换架构不改代码
