面试复习计划（6周，偏 System Design）

适用背景：

• 你大约有 10 年工作经验
• 距离上一次正式面试已经有 6–7 年
• 目标不是短期猛冲刷题，而是恢复“面试语境”与表达能力
• 重点是 System Design，LeetCode 作为保底
• 每天可投入 30 分钟到 1 小时，周末可适当多一点

这个计划的目标不是让你“学完所有知识”，而是：

1. 重新建立 system design 面试框架
2. 把你原本做过的工程经验翻译成面试语言
3. 用低压力、可持续的节奏恢复信心
4. 在 6 周后具备开始试水面试的状态

总体原则

1）优先级

优先级从高到低：

1. System Design
2. 表达与复盘
3. LeetCode 保底
4. 八股/零散知识补洞

2）每天只做一件“最重要的事”

不要每天同时想做：看 DDIA、刷题、改简历、mock、投递、看八股。 每天只抓一个主任务，否则很容易累但没有积累感。

3）30 分钟版本也算完成

你的计划不是按“理想状态”设计，而是按“现实可持续”设计。 忙的时候完成 30 分钟版，也算完成当天任务。

4）复习的核心不是看懂，而是“能讲出来”

特别是 system design：

• 你不是要写论文
• 你是要在有限时间里，把问题拆清楚、方案讲清楚、trade-off 讲明白

System Design 标准答题框架

之后每一道题都尽量按这个框架练：

1. Clarify requirements

   • 先问清楚这是核心功能、规模、实时性、读写比例，还是一致性更重要

2. Estimate and prioritize

   • 简单估一下规模，明确先满足什么，后满足什么

3. High-level design

   • 先给大图，不要一上来扎进细节

4. Data model / core entities

   • 讲清楚主要数据对象、存储位置、读写路径

5. Bottlenecks and scaling

   • 哪些地方先顶不住，怎么扩展

6. Reliability and failure modes

   • 宕机怎么办、重试怎么办、消息重复怎么办、缓存失效怎么办

7. Trade-offs

   • 为什么用这个，不用那个
   • latency vs consistency
   • simplicity vs flexibility
   • cost vs robustness

你的每周固定节奏

建议固定成下面这个节奏，降低决策负担：

• 周一：理论/主题学习
• 周二：轻量 LeetCode + 一个 design 主题口述
• 周三：完整练 1 道 system design 题
• 周四：LeetCode 保底 + 知识点复盘
• 周五：再练 1 道 system design，重点练表达
• 周六：较完整的 mock / 深度复盘
• 周日：轻复习 + 总结 + 下周安排

如果某周特别忙，就保住三件事：

• 1 次完整 design 题
• 2 次短口述练习
• 2 次 LeetCode 保底

每天投入模板

A. 30 分钟最小版本

1. 5 分钟：回顾昨天笔记
2. 15 分钟：当天主任务
3. 10 分钟：口述总结 / 复盘记录

B. 45 分钟标准版本

1. 5 分钟：热启动，回顾框架
2. 25 分钟：当天主任务
3. 10 分钟：口述或写提纲
4. 5 分钟：记录问题

C. 60 分钟完整版本

1. 5 分钟：回顾
2. 35 分钟：主任务
3. 15 分钟：口述/手写框架/复盘
4. 5 分钟：记录明天做什么

第 1 周：重建基础框架

本周目标：

• 找回 system design 面试的基本结构
• 建立“答题框架感”
• 不追求深，先追求讲得完整

本周重点看：

• replication
• partitioning / sharding
• cache
• load balancer
• database primary/replica
• message queue
• CDN
• rate limiter

本周建议题目：

• URL Shortener
• Rate Limiter

周一

主题：system design 框架重建

30 分钟版：

• 写下标准答题框架 1 遍
• 用自己的话解释每一步是干什么的

60 分钟版：

• 写一版“面试时我如何开场”模板
• 例如：先澄清需求，再给高层设计，再深入数据存储和扩展点

完成标准：

• 你能不看资料，口头说出 system design 的答题顺序

周二

主题：LeetCode 保底 + 口述一个 design 主题

LeetCode：

• Array / HashMap / Two Pointers / Binary Search 里选 1 题简单或中等

System Design：

• 用 5–10 分钟口述“cache 为什么需要、常见问题是什么”

完成标准：

• 刷 1 题
• 能说出 cache 的基本作用、穿透/击穿/失效一致性的大意

周三

主题：完整练 1 道题：URL Shortener

步骤：

1. 先自己讲 15–20 分钟
2. 再写 5 分钟复盘
3. 看看自己有没有直接跳进数据库 schema 或 hash 算法细节

重点：

• ID 生成
• 读多写少
• redirect latency
• 存储与缓存
• 热点 URL

完成标准：

• 能完整讲完一遍，不追求完美

周四

主题：LeetCode 保底 + replication / sharding 复盘

LeetCode：

• 再做 1 题基础题

知识点复盘：

• 为什么要 replication
• replication 和 sharding 解决的问题分别是什么
• 各自的典型副作用是什么

完成标准：

• 能讲清“replication 不是 sharding，sharding 不是 replication”

周五

主题：完整练 1 道题：Rate Limiter

重点：

• 放在哪里做
• user / IP / token 维度
• fixed window / sliding window / token bucket
• 分布式下如何共享状态

完成标准：

• 讲出至少 2 种方案，并说明 trade-off

周六

主题：本周深度复盘

做法：

• 回看周三、周五的题
• 给自己打分：
  1. 有没有先澄清需求
  2. 有没有先给高层设计
  3. 有没有讲到扩展性
  4. 有没有主动讲 failure mode
  5. 有没有总结 trade-off

如果有 60 分钟：

• 再把 URL Shortener 或 Rate Limiter 重新讲一遍

周日

主题：轻总结

输出：

• 本周我最卡的 3 个点
• 下周最需要补的 2 个知识点
• 哪个题最适合下周再讲一次

第 2 周：存储、缓存、队列这些核心件

本周目标：

• 把常见组件讲得更像“做过系统的人”
• 开始连接到真实工程经验

本周重点看：

• SQL vs NoSQL
• cache：穿透、击穿、失效、一致性
• queue：削峰、异步、重试、幂等
• sharding：原因、方式、热点问题
• replication 的读写一致性问题

本周建议题目：

• Notification System
• Metrics / Logging System

周一

主题：SQL vs NoSQL

完成目标：

• 能说清什么时候偏向关系型，什么时候偏向 KV / document / wide-column
• 不追求“标准答案”，要能讲 trade-off

周二

主题：LeetCode + cache 口述

LeetCode：

• Stack / Queue / BFS / DFS 里选 1 题

口述：

• 解释 cache aside、大致一致性问题、热 key 怎么办

周三

主题：练 Notification System

重点：

• push / email / SMS 是否分通道
• 异步化
• 重试和死信
• 用户偏好配置
• 去重和幂等

周四

主题：LeetCode + queue / idempotency 复盘

目标：

• 能解释为什么“异步”不只是为了快，也为了削峰和解耦

周五

主题：练 Metrics / Logging System

重点：

• ingest throughput
• write path / read path
• aggregation
• index
• retention
• cost control

周六

主题：连接真实经验

输出 1 页笔记：

• 我过去做过哪些和 cache / queue / consistency / metrics 相关的事情
• 面试时怎么讲成案例

周日

轻总结：

• 哪些概念你“懂”，但讲不顺
• 哪些地方总是容易跑题

第 3 周：高频业务题 1

本周目标：

• 进入更像真实产品的问题
• 开始练“用户场景 → 架构”的转换

本周建议题目：

• Design Twitter / News Feed
• Design Chat System

关注重点：

• fanout
• timeline
• online/offline
• ordering
• unread state
• delivery guarantees
• websocket / push

周一

主题：News Feed 核心问题梳理

你至少要能回答：

• push model vs pull model
• celebrity 问题怎么处理
• feed ranking 先不先做
• timeline 存哪里

周二

主题：LeetCode + timeline 口述

LeetCode：

• linked list / interval / sliding window 里选 1 题

口述：

• 5 分钟说清 News Feed 的 read path 和 write path

周三

主题：完整练 Design Twitter / News Feed

重点：

• post service
• fanout service
• home timeline
• user follow graph
• cache
• hot users

周四

主题：LeetCode + chat system 知识点复盘

目标：

• 说清实时消息系统和 feed 系统最大的不同点

周五

主题：完整练 Chat System

重点：

• websocket / long polling
• message persistence
• sequencing / ordering
• offline sync
• unread badge
• multi-device consistency

周六

主题：表达训练

任务：

• 从本周两道题里任选一道
• 尝试不用画图，只靠口头讲清楚

这是很重要的训练，因为真实面试里很多卡顿不是不会，而是讲不顺。

周日

复盘：

• 你最容易过度展开的地方是什么
• 你最常漏掉的 failure mode 是什么

第 4 周：高频业务题 2

本周目标：

• 开始把“高级感”加进去
• 不只是能搭系统，还能谈演进、成本、观测、扩容

本周建议题目：

• File Storage / Photo Storage
• Search / Autocomplete
• Job Scheduler

关注重点：

• metadata vs blob 分离
• indexing
• async processing
• ranking
• throughput vs latency
• consistency vs freshness
• observability
• 成本和演进路径

周一

主题：File / Photo Storage

重点：

• 元数据和文件本体分开存
• 上传链路
• 缩略图/转码异步处理
• CDN 与对象存储

周二

主题：LeetCode + object storage / CDN 口述

周三

主题：Search / Autocomplete

重点：

• 索引如何建
• 前缀匹配
• ranking
• freshness
• typo tolerance（能提到即可）

周四

主题：LeetCode + indexing / ranking 复盘

周五

主题：Job Scheduler

重点：

• 任务定义
• 定时触发
• worker 执行
• retry
• 幂等
• 任务状态
• 卡死任务怎么处理

周六

主题：架构成熟度升级

把这周任意一题重讲一遍，并刻意补上：

• metrics
• alerting
• tracing / logging
• backfill / migration
• disaster recovery

周日

复盘：

• 哪些“高级点”你知道名字但还不会自然讲进去

第 5 周：模拟面试周

本周目标：

• 把前四周的内容变成“可上场状态”
• 找到自己真正的问题：不是知识不会，而是结构乱、说太快、说不透、容易跑偏

本周任务：

• 至少做 3 轮 mock
• 覆盖：
  1. 基础题
  2. 高频业务题
  3. 开放型题

周一

主题：整理开场模板

写一版你自己的 system design 开场白，目标是前 2 分钟更稳。

周二

Mock 1：基础题

• URL Shortener / Rate Limiter 二选一

复盘问题：

• 有没有先问问题
• 有没有先给高层图
• 有没有过早扎进细节

周三

Mock 2：业务题

• News Feed / Chat / Notification 二选一

复盘问题：

• 有没有把系统边界讲清楚
• 有没有清晰地区分写路径和读路径

周四

轻量日：LeetCode + 薄弱点修正

• 做 1 题保底
• 只补一个最弱的 design 点

周五

Mock 3：开放型题

• Search / File Storage / Scheduler 二选一

复盘问题：

• 有没有主动讲 observability
• 有没有主动讲 trade-off
• 有没有主动总结

周六

主题：总复盘

把 3 次 mock 的问题汇总成 1 张表：

• 我最常漏掉什么
• 我最容易讲散的是什么
• 我最不熟的基础件是什么
• 哪一类题我最虚

周日

主题：准备进入试水面试

输出：

• 下周开始时，我最适合投什么样的岗位
• 我应该先拿哪些公司练手

第 6 周：开始试水，建立市场反馈

本周目标：

• 不再只停留在“准备好了再说”
• 开始通过真实反馈校准自己

本周任务：

• 开始投一些你没那么执着、但岗位质量不错的公司
• 把真实面试当成校准器，而不是胜负判决

周一

主题：整理投递策略

建议：

• 第一批不要直接投你最想去的公司
• 先投中等优先级公司，恢复手感

周二

主题：LeetCode 保底 + 轻量设计复述

目标：

• 保持状态，不要因为投递开始就完全停掉复习

周三

主题：真实面试前准备

准备一个统一记录模板：

• 公司 / 岗位
• 问了什么
• 我哪里卡住
• 哪种题反复出现
• 对方更关注什么

周四

主题：补最近暴露的问题

只补真实面试里暴露出来的一项：

• 例如 sharding 不熟
• 例如 cache consistency 讲不清
• 例如开场过于发散

周五

主题：再做 1 次 mock 或重讲

周六

主题：阶段总结

回答：

• 跟 6 周前比，我现在最大的进步是什么
• 我现在是真的不行，还是只是还没恢复手感
• 下一阶段该继续补什么

周日

主题：建立长期维护节奏

如果 6 周后还要继续准备，建议进入长期版：

• 每周 2 次 system design 题
• 每周 2 次 LeetCode 保底
• 每周 1 次复盘或 mock
• 每次真实面试后做记录

LeetCode 最低配策略

你不是要靠刷 300 题上岸，所以 LeetCode 采用“保底不失血”策略。

每周 3 次，每次 30–45 分钟即可。

优先顺序：

1. Array / String
2. HashMap / Set
3. Two Pointers
4. Binary Search
5. Stack / Queue
6. Tree / DFS / BFS
7. Interval
8. Sliding Window
9. Heap
10. Basic Graph

原则：

• 每次只做 1 题
• 做完一定复盘
• 不要因为卡住就开始无底洞式刷题

每周复盘模板

每周日花 10 分钟回答：

1. 这周我完整讲了几道 system design 题？
2. 我最常漏掉的是哪一步？
3. 我最不熟的基础件是什么？
4. 我的表达问题是：太散、太快、太虚，还是太细？
5. 下周最该补的一个点是什么？

每道题复盘模板

每做完一道 system design，都回答这 8 个问题：

1. 需求有没有问清楚？
2. 有没有先给高层方案？
3. 数据模型清不清楚？
4. 核心瓶颈有没有指出来？
5. 扩展方案是不是自然？
6. failure mode 有没有主动提？
7. trade-off 有没有讲？
8. 如果再答一次，开场怎么优化？

如果这周特别忙，保命版这样做

一周只做这 4 件事也可以：

• 1 道完整 system design
• 2 次 10 分钟口述
• 2 道 LeetCode 基础题
• 1 次周复盘

做到这个，你就没有脱轨。

这 6 周里最重要的几件事

1. 不要和“6–7 年没面试的自己”较劲 你不是从零开始，你只是要重新适配面试这种表达场景。

2. 不要把 LeetCode 当主战场 你的优势更可能在工程判断、系统经验、trade-off 感，而不是纯刷题速度。

3. 每周至少讲出 2 道题 只看不讲，进步会很慢。

4. 尽早进入 mock 和真实反馈 不要等“完全准备好了”才开始。

5. 这不是一次考试，是恢复市场选择权 只要你能逐步恢复手感，信心会回来得比你想象中快。

附录 A：这份文件怎么直接当复习资料用

你的想法很好，而且非常适合后面整理进 Logseq。

原因很简单：

• 面试复习最怕资料分散
• 先把“行动计划 + 最小够用资料”放在一个文件里，执行成本最低
• 等你实际复习几轮后，再和我一起沉淀到 Logseq，内容会更贴近你的真实薄弱点，而不是一开始就整理一堆泛化笔记

所以建议工作流就是：

1. 先只用这一个文件复习
2. 每次复习时，把你卡住的点、你自己的表达版本、你真实做过的案例补到这份文件或旁边临时笔记里
3. 等积累一两周后，再和我一起整理成 Logseq 页面
4. Logseq 里重点沉淀“你的版本”，不是教科书版本

也就是说：

• 现在这份文件负责“能直接复习”
• 之后 Logseq 负责“长期知识资产化”

附录 B：System Design 面试速查总表

1）面试开场模板

你可以直接照着这个逻辑说：

1. 我先确认一下需求和边界
2. 然后我会给一个 high-level design
3. 接着展开数据模型、读写路径和核心组件
4. 然后讨论瓶颈、扩展性、可靠性和 trade-off
5. 如果时间允许，我再补充监控、容灾和演进方案

一个更自然的中文表达：

“我先快速澄清一下需求和规模，然后给一个高层设计。接着我会展开核心数据模型和主要读写链路，再讨论系统的瓶颈、扩展方式、失败场景以及 trade-off。如果有时间，我最后会补充监控、容灾和后续演进。”

2）澄清需求时常问的问题

每道题先问这些，不需要全问，选最重要的：

• 核心功能是什么？
• 是单一核心场景，还是多功能产品？
• DAU / QPS / 数据规模大概什么级别？
• 更在意 latency、throughput，还是 consistency？
• 读多写少还是写多读少？
• 是否要求强一致？
• 是否需要多地区部署？
• 是否要求实时？
• 数据需要保留多久？
• 有没有排序、搜索、推荐、通知这类衍生需求？

3）常用高层组件及一句话用途

• Load Balancer：把流量分到多台服务实例
• App Server：处理业务逻辑
• Cache：降低延迟、减轻数据库压力
• Primary DB：主写入数据源
• Read Replica：分担读请求
• Message Queue：异步化、削峰、解耦
• Worker：处理异步任务
• Object Storage：存图片、视频、文件等大对象
• Search Index：支持全文检索、前缀搜索、排序
• CDN：把静态资源分发到更靠近用户的边缘节点
• Rate Limiter：限制请求频率，保护系统
• Metrics / Logs / Traces：观测系统健康与问题

附录 C：核心基础件速记资料

1）Replication

它解决什么：

• 提高可用性
• 提升读吞吐
• 给故障切换留余地

代价：

• 有复制延迟
• 读写一致性会变复杂
• failover 和主从切换有运维复杂度

面试里要主动提：

• 写先到 primary
• 读可以走 replica
• replica lag 会带来 stale read
• 如果强一致要求高，关键读请求不能随便走 replica

一句话总结：

• replication 主要是为高可用和读扩展，不是为水平切分数据

2）Sharding / Partitioning

它解决什么：

• 单库单表装不下
• 单机吞吐不够
• 需要把数据和流量横向分散

常见分片方式：

• 按 user_id hash
• 按 region
• 按时间
• 按业务域

典型问题：

• 热点分片
• 跨分片查询麻烦
• 跨分片事务复杂
• 扩容和数据迁移成本高

一句话总结：

• sharding 主要是为写扩展和容量扩展，但会增加查询、迁移和事务复杂度

3）Cache

它解决什么：

• 降低读延迟
• 扛热点流量
• 保护下游数据库

常见模式：

• Cache Aside：先读 cache，没有再查 DB，然后回填 cache
• Write Through：写 DB 时同步写 cache
• Write Behind：先写 cache，稍后异步落 DB（面试里少用，复杂）

常见问题：

• Cache miss：第一次没命中
• Cache breakdown：热点 key 失效瞬间打爆 DB
• Cache penetration：恶意/无效 key 持续穿透到 DB
• Cache inconsistency：DB 和 cache 不一致

常见解法：

• TTL 加随机抖动
• single flight / request coalescing
• 布隆过滤器
• 热 key 保护
• 双删或版本控制

一句话总结：

• cache 是最常见的加速手段，但真正难点往往在一致性和热点保护

4）Message Queue

它解决什么：

• 异步化
• 解耦
• 削峰填谷
• 重试与失败隔离

常见面试点：

• at-most-once / at-least-once / exactly-once 语义
• 重试会导致重复消费
• 所以消费者要幂等
• 要有 dead letter queue
• 失败任务不能无限重试

一句话总结：

• queue 让系统更稳，但会把同步复杂度变成异步一致性复杂度

5）Load Balancer

用途：

• 流量均衡
• 故障实例摘除
• 支持水平扩展

要点：

• health check
• sticky session 是否需要
• L4 / L7 区别知道概念即可

一句话总结：

• 没有 LB，多实例扩容就很难优雅落地

6）CDN

用途：

• 把静态资源放到离用户更近的边缘节点
• 降低源站压力
• 加快静态内容访问

适合：

• 图片
• 视频
• JS/CSS
• 下载文件

一句话总结：

• CDN 本质是内容分发和边缘缓存，不是业务数据强一致系统

7）Rate Limiter

目标：

• 防刷
• 防滥用
• 保护系统
• 对不同租户或用户做配额控制

常见算法：

• Fixed Window：简单，但边界突刺明显
• Sliding Window Log：精确，但存储重
• Sliding Window Counter：折中
• Token Bucket：常见，允许一定 burst
• Leaky Bucket：更平滑

面试里常说：

• 小系统可在应用层做
• 分布式系统可把计数放 Redis
• key 可以是 user_id / IP / API key / tenant_id

8）SQL vs NoSQL

什么时候偏 SQL：

• 强事务
• 复杂查询
• schema 相对稳定
• 数据关系清晰

什么时候偏 NoSQL：

• 高吞吐
• schema 更灵活
• 简单 key-based 访问模式
• 大规模横向扩展优先

不要说成“SQL 旧、NoSQL 新”。 真正该说的是：

• 数据模型
• 查询模式
• 一致性要求
• 扩展方式
• 团队复杂度承受能力

9）Observability

面试里这是加分项。 至少要会主动补这三件事：

• Metrics：QPS、error rate、latency、queue lag、cache hit ratio
• Logs：错误日志、审计日志、关键业务日志
• Traces：跨服务链路排查

再往上一步：

• alerting
• SLO / SLA
• dashboard
• capacity planning

附录 D：高频题最小复习资料

1）URL Shortener

核心需求：

• 长链接转短链接
• 访问短链接时重定向到原链接
• 需要高可用、低延迟

核心组件：

• API service
• ID generator
• DB（short_code -> long_url）
• Cache
• 可选 analytics pipeline

关键问题：

• 短码如何生成：自增 ID + Base62，或随机码
• 如何避免冲突
• 热门短链接会不会成为热点
• redirect 延迟怎么降

常见 trade-off：

• 自增 ID 简单，但可预测
• 随机码不可预测，但冲突处理更复杂

一版很稳的答题骨架：

• 先澄清是否需要自定义 alias、过期时间、点击统计
• 写路径：创建短链 -> 生成 code -> 落 DB -> 返回短链
• 读路径：收到短链 -> 查 cache -> miss 查 DB -> 回填 cache -> redirect
• 扩展：热点缓存、只读副本、异步统计

2）Rate Limiter

核心需求：

• 对用户/IP/API key 限流
• 防止系统被打爆
• 允许合理 burst 或平滑流量

核心组件：

• API gateway / middleware
• Redis / in-memory counter
• policy config

关键问题：

• key 用什么维度
• 限制粒度是什么：每秒、每分钟、每天
• 多机部署如何共享状态
• 算法选哪种

稳妥表达：

• 小规模可本地内存
• 分布式推荐 Redis + token bucket / sliding window counter
• 要注意时钟、过期、热点 key、Redis 可用性

3）Notification System

核心需求：

• 发送站内信、邮件、短信、push
• 支持用户偏好
• 支持失败重试

核心组件：

• notification API
• template service
• queue
• channel workers
• provider adapters
• user preference store

面试要点：

• 不同渠道解耦
• 异步发送
• provider 失败重试
• 幂等去重
• 退避重试 + dead letter queue

4）Metrics / Logging System

核心需求：

• 高吞吐写入
• 聚合查询
• retention
• 低成本存储

要点：

• 写路径和读路径分离
• 原始日志和聚合数据分层存储
• 时间序列适合按时间分区
• logging 更偏 append-heavy
• metrics 更关注聚合、降采样、label/cardinality

5）News Feed / Twitter

核心需求：

• 发帖
• 关注用户
• 查看 home timeline
• 查看用户自己的 timeline

关键矛盾：

• push model：写时扇出，读快但写重
• pull model：读时聚合，写轻但读重
• celebrity 用户会打爆 push fanout

稳妥说法：

• 普通用户可以 push fanout
• 大 V 可以 hybrid 或 pull on read
• timeline 通常会缓存
• 排序先按时间，复杂 ranking 可后置

6）Chat System

核心需求：

• 实时消息
• 在线/离线
• 多端同步
• 消息顺序
• 未读状态

关键点：

• websocket 常见
• 消息先持久化再 ack 更稳
• 群聊与单聊扩展复杂度不同
• 顺序一般只能做到 conversation 内局部顺序
• 离线用户需要 sync backlog

7）File / Photo Storage

核心需求：

• 上传文件
• 存储原文件
• 生成缩略图/转码
• 下载/展示快

关键点：

• 元数据与 blob 分离
• 文件本体放对象存储
• 缩略图/转码走异步 pipeline
• CDN 加速读路径
• 权限控制和签名 URL 常见

8）Search / Autocomplete

核心需求：

• 输入时快速返回候选
• 结果排序合理
• 数据持续更新

关键点：

• 倒排索引 / trie 知道概念即可
• prefix match
• ranking
• freshness
• typo tolerance 能提到是加分项

9）Job Scheduler

核心需求：

• 定时触发任务
• 任务可重试
• 可监控状态
• 失败可恢复

关键点：

• scheduler 决定什么时候发任务
• worker 决定谁去执行
• 任务要幂等
• retry/backoff
• stuck job recovery
• 任务状态机：pending / running / success / failed / retrying

附录 E：LeetCode 保底题型速记

你不需要题海战术，只需要维持基本手感。

1）Array / String

常见套路：

• 双循环优化成 HashMap
• 前缀和
• 双指针
• 滑动窗口

2）HashMap / Set

典型用途：

• 去重
• 计数
• O(1) 查询
• 记录上次出现位置

3）Two Pointers

适合：

• 有序数组
• 回文
• 去重
• 区间收缩

4）Binary Search

不要只记模板，要会识别“答案空间单调性”。

5）Stack / Queue

适合：

• 括号匹配
• 单调栈
• BFS
• 最近更大/更小元素

6）Tree / DFS / BFS

面试保底高频：

• 遍历
• 最大深度
• 层序
• 最近公共祖先

7）Interval

高频思路：

• 排序
• merge
• 扫描线

8）Sliding Window

常见信号：

• 子串
• 连续区间
• 最长/最短满足条件

附录 F：每日复习资料对应表（按周）

下面这张表的目的，是让你每天不用再想“今天要翻什么资料”。

第 1 周对应资料

周一：

• 看附录 B 的“面试开场模板”和“澄清需求”
• 看附录 C 的总表，至少通读 replication / sharding / cache / queue / rate limiter
• 输出：写出你自己的答题框架

周二：

• 看附录 C 的 Cache
• LeetCode 只做 1 题 Array / HashMap / Two Pointers / Binary Search
• 口述：cache 为什么需要、有哪些坑

周三：

• 看附录 D 的 URL Shortener
• 按“核心需求 -> 写路径 -> 读路径 -> 扩展 -> trade-off”讲一遍

周四：

• 看附录 C 的 Replication 和 Sharding
• LeetCode 做 1 题基础题
• 口述：这两个东西各自解决什么问题

周五：

• 看附录 C 的 Rate Limiter
• 看附录 D 的 Rate Limiter
• 讲 2 种限流算法，并说明什么时候用 Redis

周六：

• 重看本周你最卡的一题
• 再看附录 B 的答题框架
• 对照每道题复盘模板打分

周日：

• 只看你的复盘，不开新资料
• 写出下周要重点补的 2 个点

第 2 周对应资料

周一：

• 看附录 C 的 SQL vs NoSQL
• 用你自己的项目举 2 个例子：为什么这类场景更偏 SQL / NoSQL

周二：

• 看附录 C 的 Cache
• LeetCode 做 Stack / Queue / BFS / DFS 之一
• 口述 cache aside、热点 key、一致性

周三：

• 看附录 D 的 Notification System
• 重点讲 queue、worker、provider adapter、retry

周四：

• 看附录 C 的 Message Queue
• 口述幂等、重试、死信队列
• LeetCode 保底 1 题

周五：

• 看附录 D 的 Metrics / Logging System
• 再看附录 C 的 Observability

周六：

• 只做一件事：把过去真实做过的 cache / queue / metrics 经验写成面试案例

周日：

• 复盘哪些点“你知道概念，但还讲不顺”

第 3 周对应资料

周一：

• 看附录 D 的 News Feed / Twitter
• 重点理解 push vs pull vs hybrid

周二：

• LeetCode 做 linked list / interval / sliding window 1 题
• 口述 timeline 的读写路径

周三：

• 再看附录 D 的 News Feed / Twitter
• 完整讲一遍

周四：

• 看附录 D 的 Chat System
• 口述它和 News Feed 最大的架构差别

周五：

• 再看附录 D 的 Chat System
• 完整讲一遍 websocket、持久化、顺序、多端同步

周六：

• 本周任选 1 题，不画图只口述
• 同时看附录 B 的开场模板

周日：

• 复盘最容易讲散的地方

第 4 周对应资料

周一：

• 看附录 D 的 File / Photo Storage
• 重点理解 metadata 与 blob 分离、异步处理、CDN

周二：

• LeetCode 保底 1 题
• 回看附录 C 的 CDN 和 Object Storage 相关段落

周三：

• 看附录 D 的 Search / Autocomplete
• 重点讲 prefix、ranking、freshness

周四：

• LeetCode 保底 1 题
• 再看附录 C 的 Observability

周五：

• 看附录 D 的 Job Scheduler
• 重点讲 scheduler / worker / retry / state machine / stuck job

周六：

• 把这周任意一题再讲一次
• 刻意补 metrics、alerting、disaster recovery

周日：

• 只复盘，不开新坑

第 5 周对应资料

本周没有新资料，核心是反复使用：

• 附录 B：答题框架
• 附录 C：基础件速记
• 附录 D：高频题最小资料

你每次 mock 前只做 2 件事：

1. 读 2 分钟开场模板
2. 读 3 分钟该题对应的最小资料

第 6 周对应资料

本周重点不是新增学习，而是根据真实面试反馈回看：

• 如果暴露的是 cache consistency，就回附录 C 的 Cache
• 如果暴露的是 sharding，就回附录 C 的 Sharding
• 如果暴露的是 queue / retry / idempotency，就回附录 C 的 Queue
• 如果暴露的是题型表达，就回附录 D 对应题目

附录 G：真实面试/Mock 时可直接使用的追问清单

当你讲到一半卡住时，就从这里挑一条继续展开：

• 这个系统最先爆的点会是什么？
• 如果读流量暴涨 10 倍怎么办？
• 如果写流量暴涨 10 倍怎么办？
• 热点用户/热点 key 怎么办？
• 如何做故障隔离？
• 如何监控系统健康？
• 如何做重试，如何避免重复处理？
• 如果需要多机房/多 region，哪些设计要改？
• 哪些地方可以先做简单版，后续再演进？
• 当前方案最大的 trade-off 是什么？

附录 H：你在复习时最该产出的笔记类型

后面整理到 Logseq 时，优先保留这几类内容：

1. 你自己的开场模板
2. 每道高频题的“我的讲法”
3. 你容易漏掉的 checklist
4. 你真实项目里能映射到面试的案例
5. 你每次 mock / 真实面试后的复盘

不要优先整理成那种“百科全书式知识点”。 更有价值的是：

• 你会怎么讲
• 你曾经怎么卡住
• 你现在怎么修正

这个才是最适合沉淀进 Logseq 的东西。