企业官网建设流程全解析

system-design-notes：短链生成2大方案对比：随机哈希 vs 自增ID，怎么选？

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes

system-design-notes是系统设计面试书籍《System Design Interview - An Insider's Guide》的配套学习笔记，其中"Design a URL Shortener"一章系统讲解了短链生成的核心设计。本文基于该章节内容，带你完整对比短链服务中最经典的两种短链生成方案——随机哈希（Hash）与自增ID（Base62转换），帮你搞清楚两者的取舍逻辑。读完你不仅掌握短链系统的选型思路，还能顺手拿下系统设计面试中的这道高频题 🎯。

1️⃣ 短链系统要解决什么问题？

一个像 TinyURL 这样的短链服务，通常要满足这样的需求：

• 生成的短链必须唯一，且尽可能短；
• 每天要处理1亿次短链生成，并支撑10年的数据量；
• 读写比例约为10:1（短链点一次，背后可能是十次查询）。

核心流程其实就两步：缩短（把长 URL 变成短码）和重定向（短码还原回长 URL）。


对应的 API 也很直接：

2️⃣ 方案一：随机哈希 + 碰撞处理

思路很直观：对长 URL 做一次哈希（如 CRC32、MD5、SHA-1），取哈希值的前 7 个字符作为短码。


优点：短链长度固定，而且不需要全局唯一 ID 生成器，各台服务器可以独立工作。

麻烦点在于哈希碰撞——两个不同长 URL 可能算出相同的前 7 位。处理方式是把longURL + 一段预定义字符串重新哈希，直到不冲突为止（也可以借助布隆过滤器加速查重）。整个流程如下：


3️⃣ 方案二：自增ID + Base62 转换

给每条短链分配一个自增 ID，再把 ID 用Base62（0-9、a-z、A-Z共 62 个字符）编码，就得到了短码。例如 ID2009215674938转换后就是zn9edcu。

7 位 Base62 能表示3.5 万亿个唯一短链，完全够用 10 年 3650 亿条记录的需求 ✅


流程是：先查库看 longURL 是否已存在（存在就直接返回旧短链），否则生成新 ID → Base62 转换 → 存下<id, shortURL, longURL>映射。

关键依赖：短链服务是多台无状态 Web 服务器扛量，所以 ID 必须由分布式 ID 生成器统一发放（比如票证服务器模式），相关设计可参考项目中的 07. Unique-Id Generator/Readme.md：


更精细的 ID 结构（如雪花算法，把时间戳、机器号、序列号拼进 64 位 ID）也在同一章有图解。

4️⃣ 两种方案怎么选？

这正是面试中最爱追问的部分，官方笔记的对比结论如下：

选型口诀：

• 追求实现简单、短链定长→ 选随机哈希，但要做好碰撞兜底；
• 追求绝对无冲突、可审计→ 选自增 ID + Base62，代价是引入 ID 生成器，且短码可被遍历猜测（建议可对 ID 做混淆处理）。

详细推导见 08. URL Shortener/Readme.md。

5️⃣ 加分项：重定向与 301/302

短链生成之后，访问侧的性能主要靠缓存支撑（10:1 的读写比意味着读路径是绝对热点）：


重定向状态码也值得在面试中提一句：

• 301（永久重定向）：浏览器会缓存结果，后续请求不再打到短链服务，省流量但无法统计点击；
• 302（临时重定向）：每次都经过短链服务，适合做点击分析。


📝 小结

• 短链生成的两大方案：随机哈希省掉了 ID 生成器但需处理碰撞；自增 ID + Base62天然无冲突但依赖分布式 ID 服务；
• 短链系统是"无状态 Web 层 + 缓存 + 数据库分片"的经典组合，读路径性能靠缓存扛；
• 掌握这套对比逻辑后，配合 01. Scaling/Readme.md 的扩展思路，面试回答会更完整。

想继续深入短链系统的完整设计，可直接阅读项目中的 08. URL Shortener/Readme.md，图文对照，效率拉满 🚀

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes