昨晚一个 4 年经验的粉丝在群里复盘 B 站（哔哩哔哩）的后端二面，人有点麻。
面试官问了一个非常贴合 B 站业务场景的题目：“B 站的视频、动态、弹幕都能点赞。面对千亿级数据量、几十万 QPS 的流量，这个点赞系统你怎么设计？”
这哥们心想，点赞不就是一个 count + 1 吗？自信回答：“简单！用 Redis 存点赞数，MySQL 持久化。用户点赞就写 Redis，异步刷回 MySQL。为了防刷，再加个限流。”
面试官听完，抛出了三连追问：
“周杰伦发新歌，流量瞬间打爆热点，你的 Redis 单分片扛得住吗？”
“点赞记录超过 1000 亿 条，Redis 存不下，MySQL 分库分表成本太高，怎么降本增效？”
“内存聚合写入时服务宕机了怎么办？数据丢了？Redis 挂了怎么降级？”
这哥们瞬间哑火，才意识到自己把“国民级 App”的架构想简单了。
兄弟们，点赞系统看似简单，实则是高并发（High Concurrency）与海量存储（Big Data）的双重噩梦。
今天 Fox 结合 B 站的真实架构演进，带你拆解这道题的 3 种段位。
一、 为什么 “简单的 Redis + MySQL” 是死路？
在小公司，Redis + MySQL 确实够用。但在 B 站这种体量（读 QPS 30w+，写 QPS 1.5w+，数据量千亿级），简单架构有两个死穴：
写穿透（Write Penetration）：如果每次点赞都直接落库，或者 Redis 没拦住，1.5 万的 TPS 能把 MySQL（甚至 TiDB）的 CPU 打满。
热点雪崩（Hotspot）：像“周杰伦发歌”这种超级热点，流量会集中打向 Redis 的某一个分片（Sharding），导致单节点过载。
结论：必须上“多级缓存”和“智能聚合”。
二、 核心架构：3 种主流解法（从青铜到王者）
解法 1：Redis Cache Aside（标准版）—— 青铜段位
这是最基础的解法。
数据结构：
点赞数：String 结构 count:business:id。
点赞列表：ZSet 结构 user:likes:id。
持久化：数据库存流水表和计数表。
Fox 点评：能跑，但扛不住热点，且 ZSet 会无限膨胀。必须限制 ZSet 的长度（比如只存最近 500 条），老的走 DB 回源。
解法 2：WAL + 智能聚合（防丢数据）—— 黄金段位
面对 1.5w+ 的写 QPS，B 站采用了 “内存聚合 + WAL” 策略。
逻辑：
写内存：用户点赞，先在应用层内存中 hold 住。
WAL 日志（关键）：为了防止服务宕机导致内存中未合并的数据丢失，先写一条本地日志（Write Ahead Log）。
动态窗口聚合：不是死板的 10 秒，而是根据当前流量水位，动态调整聚合窗口（1s - 10s）。将同一稿件的点赞数合并（count + N），同时记录用户 ID 用于去重。
异步落库：聚合后的数据通过 MQ 异步写入持久层。
优势：数据库的 IO 次数减少了数千倍，且通过 WAL 保证了准实时一致性。
解法 3：三级存储 + TaiShan KV（B 站真题）—— 王者段位
这是 B 站目前的生产级架构，核心在于“热点隔离”和“极致降本”。
1. 扛得住：热点治理三板斧
为了应对超级热点，B 站设计了 L1 + L2 防御体系：
热点探测（HotKey Detector）：实时统计流量，精准识别出“周杰伦”这种热 Key。
L1 本地缓存（Caffeine）：识别到热点后，直接利用 Caffeine 将数据缓存在应用节点本地（Local Cache），并开启 Window-TinyLfu 淘汰策略。请求直接返回，连 Redis 都不用查。
L2 分布式缓存（Redis Cluster）：承载常规流量。
2. 存得下：TaiShan KV + TiDB
数据量千亿级，Redis 存不下，MySQL 存不起。
核心存储（TaiShan KV）：B 站自研的高性能 KV 存储。利用 SSD 盘存储冷热数据，成本仅为 Redis 的 1/10。它不再是“归档”，而是主力存储。
Key 设计：{业务类型}{实体ID}{用户ID}，支持高吞吐的 Exists 查询（判断用户是否点赞）。
3. 容灾降级（保命绝招）
TiCDC 同步：数据库与缓存之间的数据一致性，通过 TiCDC（TiDB 的变更日志捕获）来实现，而不是业务层双发。
乐观更新（Optimistic UI）：如果后端挂了，前端直接反馈“点赞变红”，给用户成功的错觉，后台默默重试或等服务恢复。用户体验第一。
三、 最后的“防杠”指南（扫清死角）
设计完架构，面试官会追问这 3 个实战死角，答不上来也是挂：
Q1：L1 本地缓存（Caffeine）各节点数据不一致怎么办？
答：“接受短暂不一致。 对于点赞数这种非强一致数据，A 节点显示 100W，B 节点显示 99W，完全不影响业务。 等到热点消退或 TTL 过期，数据自然会追平 Redis/DB 中的真实数据。”
Q2：聚合写入时，用户刚点赞，刷新页面发现没变红（数据没落库），怎么办？
答：“读写分离 + 客户端乐观更新。
客户端侧：用户点赞后，前端直接把按钮变红（乐观 UI），不需要等后端返回最新 count。
服务端侧：读接口优先读Redis 里的实时聚合态（包含内存中未落库的增量），而不是读 DB。这样保证用户能看到自己的操作。”
Q3：Redis 挂了，TaiShan 扛得住吗？
答：“多级降级策略。
存储降级：Redis 挂了，流量打到 TaiShan KV（它本身就是高性能 KV，读性能强于 MySQL）。
功能降级：如果 TaiShan 也抖动，立刻关闭‘点赞数’的实时展示（显示 999+ 或静态值），只保留‘点赞状态’查询，保住核心体验。”
四、 面试标准答案模板（建议背诵）
下次被问到“B 站/抖音 点赞系统设计”，直接按这个套路输出：
“对于点赞这种千亿级数据、突发热点的系统，我的架构遵循 ‘多级缓存 + 存储降本 + 异步聚合’：
流量防御（Caffeine + Redis）：引入HotKey 探测，利用Caffeine做本地缓存抗住超级热点；常规流量走 Redis Cluster。
写入优化（WAL + 聚合）：采用动态窗口内存聚合策略，并配合WAL 日志防止宕机丢数据，将 DB 写入压力降低 3 个数量级。
海量存储（TaiShan KV）：放弃传统的 MySQL 分表，采用自研KV 存储（TaiShan）作为核心底座，配合TiCDC保证数据一致性，实现极致的降本增效。
体验兜底：前端采用乐观更新策略，后端具备Railgun 降级能力，确保极端情况下服务不雪崩。”
写在最后
架构设计没有完美的方案，只有被业务逼出来的方案。 B 站的点赞系统之所以复杂，是因为它要在“周杰伦发新歌”的洪峰下，依然保持丝滑。把“热点”隔离，把“成本”打下来，把“容灾”做到底，你就是架构师。
https://mp.weixin.qq.com/s/T_5xDocvTSKFkcuM0yl4qA
