30 分钟白板演练用刷榜笔记的思路手写一份短链系统设计【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes系统设计面试里短链URL Shortener几乎是出场率最高的入门级题目需求容易理解、边界清晰、却又藏着容量估算、ID 生成、缓存、重定向语义等一连串值得深挖的点。正因为它看着简单、问起来没底最适合拿来当白板演练的练习场。这份仓库把《System Design Interview》拆成了 28 章每章都是一次完整的需求澄清 → 高层设计 → 深潜 → 复盘推演短链对应其中的 第 8 章。本文就借用这套刷榜笔记的思路把一次 30 分钟的白板演练完整走一遍先钉死需求再算清楚容量然后做选型对比最后把方案讲出来——每一步都有仓库里的笔记和示意图作支撑你可以直接照着白板复刻。一、白板第一笔先把需求钉死在白板上面试官抛出设计一个短链服务后最容易犯的错误是立刻画架构图。按照 03. System Design Framework/Readme.md 里的框架前几分钟应该用来澄清问题、写下假设而不是动手设计。白板上至少要先出现这几行功能长链转短链、短链访问时 302/301 重定向到长链量级每天生成 1 亿条短链支持 10 年容量读写特征读:写 10:1这是决定缓存和数据库架构的关键数字非功能短链尽量短、全局唯一、高可用、低延迟。其中读写比 10:1这一条尤其重要——它直接决定了后面所有架构决策的方向读多写少意味着必须上缓存、必须做读路径优化而写入路径可以做得相对重一些。把假设写在白板上还有个额外好处面试官会把你当成协作者而不是被考核者后续讨论就有了共同的语言锚点。二、容量估算把 QPS 和存储算到白板上有了量级就可以套用 02. Back Of the Envelope Estimation/Readme.md 里教的方法做封底估算。这一步的价值不在算得准而在于展示你的量级感和推导过程所以别用计算器心算即可。QPS 估算写入 QPS 1 亿 / 86,400 秒 ≈1,160 QPS读取 QPS 1,160 × 10 ≈11,600 QPS峰值读 QPS 按 2 倍毛估 ≈23,000 QPS存储估算每年记录数 1 亿 × 365 365 亿条10 年累计 3,650 亿条仓库笔记里的口径是 365 billion按每条记录ID 短链 长链 索引开销约 1KB 毛估十年总存储 ≈365 TB估算时2 的幂换算能力是基本功仓库第一章就给出了这张对照表缓存估算读请求 11,600 QPS 意味着每天约 10 亿次访问。按经典的 80/20 规则大约 20% 的热门短链扛走了 80% 的流量。只要把热点映射shortURL → longURL每条约 500B缓存住就能把绝大多数读请求挡在数据库之外——缓存 100 万条热点大约只需要 500MB 内存量级完全可控。这个算完才知道该缓存多少的过程正是刷题笔记里反复强调的从量级反推组件的思维。最后在白板上汇总成一张表面试官一眼就能看出你对量级有掌控指标估算值写入 QPS~1,160读取 QPS~11,600峰值 ~23,00010 年总记录数3,650 亿条10 年总存储~365 TB热点缓存20% 热门短链约 500MB 级三、架构选型为什么是发号器 Base62而不是 UUID容量算完白板进入深潜阶段。短链系统最核心的技术决策只有一个短链怎么生成仓库 08. URL Shortener/Readme.md 给出了两条经典路线对比非常清晰路线一哈希截断 碰撞解决。对长链取 MD5 / SHA-1 / CRC32截取前 7 位作为短链。优点是长度固定、不需要 ID 生成器缺点是哈希会碰撞需要反复追加字符串重哈希或借助布隆过滤器判重成本高且不可控。路线二发号器 Base62 编码。由一个全局唯一的 ID 生成器发号再把十进制 ID 转成 Base62 字符串。62 个字符[0-9, a-z, A-Z]能承载的量级非常可观7 位 Base62 可表示 62⁷ ≈ 3.5 万亿种组合覆盖 3,650 亿条记录绰绰有余。仓库笔记里给了个具体例子ID2009215674938转 Base62 后得到zn9edcu正好 7 位。那为什么社区里普遍否决 UUID因为它有三个硬伤笔记里记得清清楚楚太长UUID 是 128 位标准字符串形式 36 个字符与短链要短的初衷直接矛盾不可排序生成无序无法按时间组织、难以做时间维度的统计与分页不可预测递增无法承载下一个可用短链这类语义。那 Twitter Snowflake 呢它本身是优秀的分布式 ID 方案但直接用于短链会撞上另一个问题位数膨胀。Snowflake 的 64 位 ID 转 Base62 后大约有 10~11 位明显超出 7 位的短链预期而且其中的数据中心 ID、机器 ID 位对短链业务毫无意义白白占用编码空间。所以短链场景的正确答案是发号器 Base62这对组合唯一性由发号器保证编码只负责变短。发号器可以是简单可靠的方案——比如集中式 ticket server一个自增计数器或者 Redis 的INCR批量取号一次取一段区间如[100000, 100999]本地逐号消费代价小、可控性强。笔记里那句Collision is not possible正是这条路线最大的卖点编码是双射天然无碰撞根本不需要判重。两条路线的完整权衡仓库里的对比表可以直接搬上白板维度哈希截断 碰撞解决发号器 Base62短链长度固定随 ID 增长初期可保持 7 位依赖不需要 ID 生成器需要全局发号器碰撞可能需要额外解决不可能可预测性不可预测ID 自增时可被枚举安全考虑四、数据模型与两条核心链路选型定了剩下的就是把流程画通。存储上采用关系型数据库保存shortURL, longURL映射表结构非常简单白板上画三列即可CREATE TABLE url_map ( id BIGINT PRIMARY KEY, -- 发号器分配的全局唯一 ID short_url VARCHAR(7) NOT NULL, -- Base62 编码结果 long_url VARCHAR(2048) NOT NULL, UNIQUE KEY uk_short_url (short_url) );链路一短链生成。请求进来后先查长链是否已存在存在则直接复用否则向发号器取 ID、转 Base62、落库。注意先查重这一步非常关键——它让同一个长链始终得到同一个短链避免了数据膨胀链路二短链重定向。用户点击短链后先查缓存Redis未命中再查数据库拿到长链后返回重定向响应这里有个几乎必问的点301 还是 302301 表示永久移动浏览器会缓存结果后续请求不再打到短链服务服务端压力小302 表示临时重定向每次访问都会经过服务端方便做点击统计与来源分析。仓库笔记的结论是如果业务需要分析能力选 302如果纯粹为了减负选 301。这个二选一的回答本身不复杂难的是把背后的取舍逻辑讲清楚——而取舍逻辑正是白板演练要练的核心。五、白板表达练习30 分钟讲法拆解技术方案想清楚了最后一步也是最容易被忽视的一步怎么在 30 分钟内把这张白板讲完整。刷榜笔记的思路在这里同样适用——表达节奏也要像笔记目录一样结构化。参考 03. System Design Framework/Readme.md 里的四步框架45 分钟版本是 3-10 / 10-15 / 10-25 / 3-5 分钟压缩到 30 分钟可以这样切阶段时间白板上的内容表达要点澄清需求0-5 min功能清单 量级假设 读写比多问问题把假设写下来高层设计5-12 min框图客户端 → 负载均衡 → 短链服务 → 发号器 → 缓存 → 数据库先整体后细节主动给出估算深潜12-22 minBase62 与哈希对比、301/302、缓存策略聚焦 1-2 个关键组件展示权衡收尾22-30 min瓶颈清单 扩展方案主动暴露弱点给出演进路线四个阶段的表达各有侧重澄清阶段展示的是你如何看待模糊需求高层设计展示的是你是否有全局观和量级感深潜阶段展示的是你是否真的理解技术选型背后的取舍收尾阶段展示的是你是否知道这套方案会在哪里崩。练到后期还可以给自己准备一份追问清单模拟面试官可能的连招。仓库里各章的 Additional Considerations 就是现成的题库301 还是 302—— 重定向语义与统计需求之间的取舍同一个长链反复提交怎么办—— 查重复用代价是每次创建多一次 DB 查询发号器挂了怎么办—— ticket server 单点故障可用 RedisINCR批量取号或雪崩备选方案兜底短链被暴力枚举怎么办—— Base62 自增 ID 可被预测可引入随机偏移/加盐并叠加限流对应仓库 04. Rate Limiter/Readme.md365 TB 单表放不下怎么办—— 按 shortURL 做一致性哈希分片对应仓库 05. Consistent Hashing/Readme.md。六、复盘这张白板还能怎么进化30 分钟结束前别忘了在白板上补最后一笔演进路径。单机 单表的设计在量级爬坡后必然遇到瓶颈你要能说出每一步怎么走Web 层保持无状态配合负载均衡水平扩容对应 01. Scaling/Readme.md 里stateless web tier的原则数据层主从复制扛读流量再按 shortURL 哈希分片扛容量可用性目标 99.9% 意味着每年约 8.8 小时停机预算02. Back Of the Envelope Estimation/Readme.md 里的可用性数字表主库故障时需要有从库提升与数据恢复预案附加能力按 IP 限流防滥用、点击与来源统计反哺业务。把这六个部分走完一次 30 分钟的白板演练就闭环了。回头看整个过程你会发现它的骨架和仓库笔记的目录几乎一一对应需求清单 → 容量估算 → 选型对比 → 核心链路 → 追问清单 → 演进复盘。这恰恰是刷题笔记的真正价值——它不给你标准答案而是把面对模糊问题时如何系统性地逼近答案这个过程拆成可以反复练习的步骤。下次在白板前拿到任何一道系统设计题都值得先用这套骨架走一遍。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考