我用 AI 模拟字节跳动三面，系统设计轮答到一半面试官沉默了
备选标题：
- 让 AI 面 AI：字节三面实录，面试官追着 Feed 流方案问了 10 分钟
- 模拟字节跳动三面，AI 求职者的 LRU Cache 写对了，但漏了一个致命细节
场景设定：字节跳动 · 后端资深工程师 · 抖音团队
参与角色：AI 面试官（Claude）vs AI 求职者（GPT-4o）
人类裁判：我（击歌吟）
🎬 第一面（基础算法）
面试官问：
实现一个 LRU Cache，支持 get(key) 和 put(key, value)，要求 get 和 put 都是 O(1)。说说你的设计思路，为什么不用 FIFO 或 LFU？
求职者答：
选「哈希表 + 双向链表」。哈希表 O(1) 查节点，链表维护访问顺序。每次访问一个 key，节点移到链表头；淘汰时删链表尾。
classDLinkedNode:def__init__(self,key=0,val=0):self.key=key self.val=val self.prev=Noneself.next=NoneclassLRUCache:def__init__(self,capacity:int):self.capacity=capacity self.cache={}self.head=DLinkedNode()self.tail=DLinkedNode()self.head.next=self.tail self.tail.prev=self.headdefget(self,key:int)->int:ifkeynotinself.cache:return-1node=self.cache[key]self._move_to_head(node)returnnode.valdefput(self,key:int,value:int)->None:ifkeyinself.cache:node=self.cache[key]node.val=value self._move_to_head(node)else:node=DLinkedNode(key,value)self.cache[key]=node self._add_to_head(node)iflen(self.cache)>self.capacity:removed=self._remove_tail()delself.cache[removed.key]def_move_to_head(self,node):self._remove_node(node)self._add_to_head(node)def_add_to_head(self,node):node.prev=self.head node.next=self.head.nextself.head.next.prev=node self.head.next=nodedef_remove_node(self,node):node.prev.next=node.nextnode.next.prev=node.prevdef_remove_tail(self):node=self.tail.prev self._remove_node(node)returnnodeFIFO 完全不考虑访问频率，可能淘汰热点数据。LFU 按频率淘汰看似公平，但维护每个 key 的计数成本高，而且存在"缓存污染"——一个 key 短期高频访问后长期不用，占着位置不释放。LRU 是平衡方案，实现简单，对多数业务场景效果够好。
🧑⚖️ 我的点评
代码结构清晰，用了虚拟头尾节点简化边界——很多候选人会漏这个细节。LRU 跟 FIFO/LFU 的对比也没跑偏。
但需要补刀的地方：
- 没提 OrderedDict。Python 3 的 OrderedDict 底层也是双向链表 + 哈希表，面试可能追问底层实现。
- LRU 的缺陷没说：批量遍历场景下，一次读操作就把整个链表顺序打乱了，热点数据可能被错误淘汰。
评分：⭐⭐⭐⭐ 通过
🎬 第二面（进阶算法）
面试官问：
抖音每天海量视频被点赞。实时返回 Top K 热门视频，热度按 24 小时内点赞数计，每 5 分钟更新一次。算法和架构怎么设计？
求职者答：
两阶段走。数据聚合层用 Redis Sorted Set（key=视频，score=点赞数），Top K 计算层维护一个最小堆。
importheapqfromdatetimeimportdatetime,timedeltaclassTopKTracker:def__init__(self,k:int,window_hours:int=24):self.k=k self.window=timedelta(hours=window_hours)self.heap=[]self.scores={}self.exists=set()defrecord_like(self,vid:str):self.scores[vid]=self.scores.get(vid,0)+1score=self.scores[vid]ifvidinself.exists:heapq.heapify(self.heap)else:heapq.heappush(self.heap,(score,vid))self.exists.add(vid)whilelen(self.heap)>self.k:_,v=heapq.heappop(self.heap)self.exists.discard(v)defget_top_k(self):returnsorted(self.heap,key=lambdax:-x[0])生产上还可以用 Count-Min Sketch 做近似计数，内存开销比精确计数小两个数量级。
🧑⚖️ 我的点评
分层的架构思路对的：消息队列 → 流计算 → 存储 → 计算 → 推送，是生产级方案。提到 Count-Min Sketch 加分。
但代码有两个问题：
heapq.heapify()是 O(n) 的！更新操作应该用heapq._siftdown或直接全量重建，面试中这可能被追问。- 没有时间衰减。24 小时点赞数如果不做衰减处理，凌晨峰值会长期霸榜。应该给更早的点赞降权。
评分：⭐⭐⭐ 通过（有瑕疵）
🎬 第三面（系统设计）
面试官问：
设计抖音关注页 Feed 流。用户打开 App → 看到关注的人发布的视频 → 按时间倒序。要求：
- 日活 3 亿，人均关注 200 人
- 发布后 10 秒内粉丝可见
- 高可用，不丢数据
画架构图，说明读写路径。
求职者答：
选推拉结合方案。大 V（粉丝 > 10 万）用拉模式，普通用户用推模式。
为什么这样设计：纯推模式下，大 V（假设 5000 万粉丝）发一条视频要写 5000 万个 Timeline，IO 爆炸。纯拉模式下，每次刷新要查 200 个关注对象的视频再 merge，延迟高。推拉结合分摊压力——大 V 只在粉丝刷新时计算，避免写放大。
存储选型：Timeline 用 Redis Sorted Set（video_id + timestamp），每个用户只存 200 条，多了就淘汰最早。关注关系用 MySQL + Redis 缓存。视频元数据用 CDN + MySQL。
🧑⚖️ 我的点评
推拉结合方案没选错。100 个面 Feed 系统的人里，70 个说纯推、20 个说纯拉、10 个能说推拉结合——你属于最后那批。大 V 阈值区分也合理。
但你漏了几个关键点，面试官大概率会换着角度追问：
- 10 秒可见怎么保证？推模式的瓶颈在写扩散延迟——一个人关注了 200 个普通用户，Timeline Cache 可能只覆盖了其中 150 人的近期视频，剩下 50 人需要 fallback 逻辑现场拉取。
- 冷启动问题。新用户刚注册关注 50 人，Timeline Cache 是空的，第一次刷新全是 miss——不预热你的数据库会被打穿。
- 容量估算。3 亿用户 × 200 条缓存 = 600 亿条记录。需要多少台 Redis？单实例扛多少 QPS？这些数字面试官很在意。
评分：⭐⭐⭐⭐ 通过
📊 总结
| 轮次 | 题目 | AI 表现 | 结果 |
|---|---|---|---|
| 一面 | LRU Cache | 基础扎实，实现规范 | ⭐⭐⭐⭐ 通过 |
| 二面 | Top K 实时排名 | 架构合理，代码有 O(n) 隐患 | ⭐⭐⭐ 通过 |
| 三面 | Feed 流系统设计 | 推拉结合，架构完整 | ⭐⭐⭐⭐ 通过 |
总体评价：三面全过。基础算法扎实，系统设计有全局视野。
比真人面试差在哪：AI 的答案"太干净"了——没有真实面试中的犹豫、追问、修修补补的过程。比如第二面的 heapify O(n) 问题，真人面试官追问一句，候选人可能直接懵掉。另外缺少了对规模的本能恐惧——600 亿个 KV 意味着什么，AI 只用一句话带过，但真实工程师会当场算机器成本。
比真人面试好在哪：覆盖面广，从数据结构的底层实现到高并发系统架构都能串起来。不会出现"这题我背过但换个说法就懵了"的情况。思维链完整：抛出方案 → 分析利弊 → 给出理由。
信息来源说明：
- ✅ 已验证：LRU Cache 双向链表实现、推拉结合 Feed 架构
- 💡 推断：大 V 阈值（10 万粉丝）为合理推测，实际字节内部阈值可能不同