系统设计笔记的本质是决策链路，不是知识搬运

1. 这不是笔记，是系统设计能力的显微镜

“system-design-notes”这个标题乍看平平无奇，像极了GitHub上成千上万份被star又沉底的个人仓库名。但如果你真点进去翻过几十份标着“System Design Notes”的文档，就会发现一个残酷事实：90%的内容停留在“画个框、连条线、写个Load Balancer”的PPT式复述层面，而真正能让你在面试中开口三分钟就让面试官坐直身体的，从来不是那些被反复搬运的CAP定理图解，而是你对“为什么必须这样设计”的肌肉记忆。我带过27位准备系统设计面试的工程师，其中19人卡在“如何把抽象原则落地为具体取舍”这一步——他们能背出“缓存穿透用布隆过滤器”，却说不清为什么不用Redis自带的SETNX做防穿透；能写出“分库分表按user_id哈希”，却解释不了当用户突然爆发性增长时，这个哈希策略会在哪一层产生雪崩。这些“notes”真正的价值，从来不是知识罗列，而是把教科书里的结论，还原成工程师在凌晨三点面对线上告警时，手指悬停在键盘上那一秒的决策逻辑。它解决的核心问题，是把“我知道”变成“我敢拍板”。适合谁？不是刚学完《数据库原理》的学生，而是已经写过两年CRUD、开始接手核心模块、但每次听到“高并发”“一致性”就下意识想查文档的实战者。关键词里没有写出来的潜台词，其实是“可验证的决策链路”——每一个设计选择背后，都必须有可量化的代价测算、可复现的压力测试数据、可回滚的演进路径。

2. 真正的Notes长什么样：从“抄概念”到“建决策树”

市面上绝大多数System Design Notes，本质是知识搬运工的产物：把《Designing Data-Intensive Applications》第几章的要点截图，配上“读完这本书你就懂了”的标题。这种笔记最大的陷阱，在于它用确定性的文字，掩盖了系统设计中本质的不确定性。真实世界里没有标准答案，只有权衡矩阵。我见过最有效的notes，从来不是按“缓存/消息队列/数据库”分章节，而是按“决策场景”组织——比如“当QPS从1k突增至50k时，你第一眼该盯哪个指标？”、“当订单状态机出现10%不一致，你是先修数据还是先堵漏？”、“新业务要接入老支付网关，接口改造和适配层，哪个成本更低？”

这类notes的结构，本质上是一棵动态生长的决策树。它的根节点永远是具体业务压力：

• 流量维度：峰值QPS、请求分布（是否脉冲型）、读写比（8:2还是3:7）
• 数据维度：单条记录大小（KB级还是MB级）、更新频率（秒级还是天级）、关联复杂度（JOIN深度、跨域调用数）
• 业务维度：一致性要求（最终一致 or 强一致）、可用性容忍（允许5分钟不可用 or 必须99.99%）、演进节奏（MVP上线周期 vs 长期架构规划）

举个真实案例：某电商秒杀系统notes里，“库存扣减”这一节点展开后，不是直接写“用Redis原子操作”，而是列出三条分支：

1. 若秒杀商品<1000件，且用户预热期已沉淀ID→ 用Redis Sorted Set + Lua脚本，理由：预热ID使请求可预测，Sorted Set天然支持按时间排序，Lua保证扣减+生成订单原子性，实测单节点扛住8w QPS；
2. 若秒杀商品>10万件，且存在大量无效请求（如机器人刷单）→ 在Nginx层加GeoIP+User-Agent白名单过滤，再接Redis布隆过滤器，理由：无效请求占70%，先过滤再进缓存，节省60% Redis内存；
3. 若需支持“阶梯价”（买10件减1元，买20件减3元）→ 放弃纯缓存方案，改用数据库行锁+应用层重试，理由：阶梯计算需读取历史购买记录，缓存无法保证实时性，宁可牺牲吞吐保正确性。

提示：所有有效notes的共性，是每个设计选择后必跟“失效条件”。比如“用Kafka做异步解耦”后面，一定标注“当消费者处理延迟>5s时，需启动死信队列+人工介入流程”。这不是悲观，而是把预案写进设计DNA。

3. 构建你的Notes：从“记下来”到“推演出来”

很多人以为notes就是把面试题答案抄一遍，结果临场发挥时大脑空白。真正有用的notes，必须经过三次“推演”才能成型：

3.1 第一次推演：逆向拆解经典题目的隐藏约束

以“设计Twitter”为例，网上90%的答案聚焦在“如何推/拉流”，却忽略题目隐含的硬约束：

• 存储成本敏感：Twitter日活5亿，若每条推文存10份副本（按关注关系），年存储成本超$2亿；
• 冷启动问题：新用户注册后，首页Feed必须在3秒内加载，不能等后台计算完成；
• 内容治理压力：需支持实时屏蔽违规账号的全部推文，不能依赖TTL过期。
  这些约束直接否定了“全量推送到粉丝Timeline”的方案，逼出“混合推拉”架构：热门用户（Top 1%）强制推送到所有粉丝，长尾用户（99%）采用拉模式+本地缓存热点Feed。你的notes里，必须把这类隐含约束单独列为一栏，和解决方案并列。

3.2 第二次推演：用真实参数替换教科书假设

教科书说“缓存命中率>95%即可”，但真实场景中：

• 若业务是新闻App，用户点击率<3%，缓存key是文章ID，那么95%命中率意味着97%的缓存空间浪费（因为80%的key只被访问1次）；
• 若业务是支付系统，缓存key是用户余额，命中率99.9%才安全（0.1%未命中=余额查询打穿DB）。
  我的做法是在notes里建一张“参数校准表”，填入自己项目的真实数据：
  | 场景 | 教科书参数 | 我的项目实测值 | 调整动作 |
  |------|------------|----------------|----------|
  | 用户会话过期时间 | 30分钟 | 平均活跃时长12分钟 | 缩短至15分钟，减少无效session占用 |
  | 消息队列重试次数 | 3次 | 99.9%失败在第1次网络抖动 | 改为指数退避+第2次重试前发告警 |
  | 数据库连接池大小 | CPU核数×2 | 实测CPU利用率仅40%时连接池已满 | 改为按TPS反推，公式：maxPoolSize = (TPS × avgQueryTimeMs) / 1000 × 1.5|

3.3 第三次推演：给每个组件画“死亡地图”

真正暴露设计缺陷的，永远是故障场景。我在notes里强制要求每个核心组件旁，附一张“死亡地图”：

• Redis集群：
  • 单节点宕机 → 客户端自动剔除，流量分摊到剩余节点（需验证分摊后QPS是否超限）；
  • 全部主节点失联 → 切换到本地Caffeine缓存，降级为30秒过期（需提前压测本地缓存GC压力）；
  • RDB持久化失败 → 启动AOF重写，但AOF文件过大导致重启慢 → 预置脚本自动清理旧AOF并触发BGREWRITEAOF。
• Kafka消费者组：
  • 消费者崩溃 → Rebalance后分区重新分配，但若处理逻辑有状态（如累加计数），需检查offset提交时机（手动commit vs auto）；
  • Topic分区数不足 → 新增分区后，Producer需重启才能感知（Kafka 2.4+支持动态感知，但旧版本需运维介入）。
    这张地图不是为了吓唬自己，而是把“理论上可行”变成“故障时能立刻执行”。

4. 面试官真正想看的：你的Notes如何暴露思考过程

系统设计面试的本质，是考察你能否把模糊需求翻译成可执行的技术契约。而你的notes，就是这份契约的草稿纸。面试官不会关心你画的架构图多漂亮，但会紧盯三个细节：

4.1 “数字感”是否真实

当你说“用CDN缓存静态资源”，面试官会问：“CDN回源率多少？如果回源率超过15%，你的缓存策略是否需要调整？”

• 错误回答：“一般CDN厂商都说95%命中率。”（教科书答案）
• 正确回答：“我们实测回源率12%，因为图片URL带UTM参数导致缓存失效。解决方案是Nginx层剥离UTM再转发，上线后回源率降至3%。”（你的notes里必须记录这个UTM参数的正则匹配规则和Nginx配置片段）

4.2 “边界感”是否清晰

当讨论“数据库分库分表”，面试官会追问：“分片键选user_id，那查询‘某城市所有用户’的需求怎么满足？”

• 错误回答：“可以用Elasticsearch同步数据。”（回避问题）
• 正确回答：“这是典型的分片键与查询维度错配。我们的notes里明确写了三种应对方案：① 建立城市→user_id映射表（增加写放大，但读快）；② 用Spark离线计算城市用户快照，每日更新（牺牲实时性）；③ 接受全库扫描，但限制查询并发数≤2，避免拖垮DB。（我们选方案②，因业务允许T+1数据）”

4.3 “演进感”是否可信

当提出“初期用单体架构”，面试官会质疑：“如何避免未来拆分时的地狱式重构？”

• 错误回答：“我们做好模块化设计。”（空洞）
• 正确回答：“在notes的‘演进路线图’里，我们定义了三个拆分里程碑：① 所有服务间调用走HTTP API（禁用直接DAO依赖），已实现；② 核心模块（订单/支付）独立部署，共享数据库但物理隔离，当前阶段；③ 数据库完全拆分，此时启用ShardingSphere做透明分库，notes里存了ShardingSphere的YAML配置模板和灰度发布checklist。”

注意：面试中展示notes，绝不是掏出手机念PPT。而是当面试官问到某个点，你自然地说：“这个问题我们在notes里专门做过压测，当时发现……”，然后用两句话讲清关键数据和结论。你的notes越“笨拙”（充满手写批注、涂改痕迹、真实错误记录），越显得可信。

5. 让Notes活起来：从静态文档到决策引擎

最危险的notes，是躺在硬盘里吃灰的PDF。真正有价值的notes，必须具备“可执行性”。我把它做成三类活文档：

5.1 可运行的验证脚本

每个设计决策旁，附一个5行以内的验证脚本。例如“用Redis Pipeline提升吞吐”这个结论，notes里不是只写理论，而是：

# 测试Pipeline vs 单命令性能差异 redis-cli --pipe << EOF SET key1 value1 SET key2 value2 SET key3 value3 EOF # 对比耗时：Pipeline 12ms vs 单命令3*8ms=24ms

再比如“Kafka消费者吞吐瓶颈在反序列化”，notes里直接放Python脚本：

# 测量反序列化耗时占比 import time, json raw_data = b'{"id":1,"name":"test"}' * 1000 start = time.time() for _ in range(10000): json.loads(raw_data.decode()) print(f"反序列化耗时: {(time.time()-start)*1000:.2f}ms")

这些脚本不是为了炫技，而是当你在真实项目中遇到类似问题时，能30秒复现验证。

5.2 可检索的故障模式库

我把历史上踩过的坑，按“现象→根因→验证方法→修复方案”结构化入库。例如：

• 现象：Kafka消费者组频繁Rebalance
• 根因：session.timeout.ms=30000，但GC停顿达35s
• 验证方法：jstat -gc <pid>查看Full GC频率，kafka-consumer-groups.sh --describe查看成员状态
• 修复方案：调大session.timeout.ms至45000，同时优化JVM参数-XX:+UseG1GC -XX:MaxGCPauseMillis=200
  这个库的价值在于，当新同事遇到同样现象，不用再花2天排查，直接按索引号查解决方案。

5.3 可演算的成本计算器

所有架构决策必须量化成本。我在notes里维护一个Excel模板（也转成Markdown表格），输入参数自动计算：

6. 最后一点私货：我的Notes里绝不写的三件事

做了十年系统设计，我逐渐明白，有些东西写进notes反而有害。以下是我在自己仓库里坚决删除的三类内容：

第一，不写“最佳实践”。这个词本身就是毒药。所谓最佳，只存在于特定约束下。我删掉了所有标题含“Best Practice”的章节，替换成“在QPS<5k、数据量<1TB、团队规模<5人的约束下，我们选择……”。因为真正的工程师，永远在约束中跳舞，而不是追逐虚幻的“最佳”。

第二，不写“技术选型对比表”。那种罗列Kafka/RabbitMQ/Pulsar特性的表格，除了制造焦虑毫无价值。我改成“我们为什么放弃RabbitMQ”：

• 原因1：RabbitMQ的镜像队列在节点故障时，消息重复投递率高达12%（我们实测数据），而业务要求幂等性由下游保证，增加开发成本；
• 原因2：RabbitMQ管理界面在10万队列时响应超时，而我们预估峰值需创建20万队列（按用户ID分队列）；
• 原因3：团队已有Kafka运维经验，学习成本为0。
  选型不是技术优劣，而是成本收益的精确计算。

第三，不写“面试高频题答案”。我把所有“设计Instagram”“设计TinyURL”的完整答案删光，只保留每个题目的“破题笔记”：

• Instagram破题点：关注关系不是图，而是双链表（用户关注列表 + 被关注列表），所以“获取我关注的人的最新10条动态”本质是10次链表遍历，而非图遍历；
• TinyURL破题点：短链ID不是随机字符串，而是62进制自增ID（a-z,A-Z,0-9），因为要保证全局唯一且可预测，避免碰撞检测的性能损耗。
  真正的竞争力，从来不在答案本身，而在你破题时，眼睛看向哪里。

现在打开你的编辑器，别急着写“缓存穿透解决方案”，先问自己：你最近一次被缓存穿透搞崩的系统，具体是什么业务场景？当时的QPS是多少？缓存失效的key有什么特征？你尝试的第一种解法为什么失败？把这些血淋淋的细节写下来，才是属于你的system-design-notes。它不会帮你拿到offer，但它会让你在真正扛起系统时，少一次凌晨三点的救火。