字节二面挂了！被问“100 亿短链接如何不重复？”，面试官：你只会用 MD5？

如何把一个 100 字符的长 URL 缩短成 6 位短码本文拆解短链接系统的底层逻辑从Base62 算法到分布式 ID 生成器从302 重定向策略到布隆过滤器防穿透。带你掌握支撑千亿级跳转的架构方案文末附面试满分模板。写在开头前两天有个兄弟跟我复盘字节跳动二面他被问到一个经典的系统设计题“我们要设计一个像 t.cn 或 dwz.cn 这样的短链接系统每天要处理亿级的新增和跳转你怎么设计”这哥们想都没想“简单啊把长链接拿去做个 MD5取前 6 位当短码存到数据库里。查询的时候根据短码查出长链接直接跳转不就行了”面试官推了推眼镜连发三问“MD5 必然会有哈希碰撞100 亿数据下两个不同长链生成了同一个短码你让用户跳哪去”“为了性能你肯定要加缓存但如果有人恶意攻击不停访问不存在的短码你的数据库瞬间就会被打挂怎么防”“HTTP 状态码你选 301 还是 302如果选错了你的运营数据统计点击量、来源全得报废你知道为什么吗”他当场宕机。其实这道题考的是“高并发系统的唯一性保证与全链路优化”。今天 Fox 带你拆解短链接系统的 3 种架构境界。一、 核心博弈HTTP 301 还是 302这是面试官考察你对业务理解的第一关。301 (Permanent Redirect)永久重定向。浏览器会缓存跳转关系下次访问直接跳不经过你的服务器。优点节省服务器压力。致命缺点****你拿不到点击数据了作为短链接服务核心价值就是统计点击量、设备信息、地区等。一旦 301你的后台统计全是 0。302 (Temporary Redirect)临时重定向。每次访问都会经过短链接服务器。优点完美统计每一次点击进行数据分析。Fox 的结论除非服务器快崩了要保命否则必须选 302。数据才是短链接系统的灵魂。二、 算法之争怎么生成那 6 位短码100 亿数据量短码长度多少才够我们通常使用Base62 编码a-z, A-Z, 0-9。如果是 6 位短码总容量是 亿如果是 7 位则是 万亿。对于 100 亿数据6 位足矣。境界 1哈希算法会有碰撞像 MD5 或 MurmurHash。痛点既然是哈希就一定有碰撞。虽然几率小但 100 亿量级下碰撞是必然。补救发现碰撞后在长链后面拼个随机字符串再重新哈希。但这会多出一次 DB 查询性能受损。境界 2自增序列法主流解法不搞哈希直接给每个长链接分配一个唯一 ID。第一个长链 ID 是 1第二个是 2...将 ID 转为 Base62 编码。比如 ID 100,000,000 转出来可能就是 6LAze。优点绝对唯一永不重复。挑战分布式 ID 的生成速度。三、 架构实现如何支撑千亿级数据1. 分布式 ID 生成器发号器单机自增肯定不行。我们可以采用类似美团 Leaf 或推特 Snowflake 的方案号段模式每次从数据库批量申请 10000 个 ID 缓存在内存里用完再去申请。优势避免频繁请求数据库支撑每秒万级以上的新增请求。2. 读写分离与缓存策略写发号器生成短码 - 存入数据库 - 存入 Redis。读先查 Redis。短链接一旦生成就不会变缓存命中率极高。布隆过滤器Bloom Filter在访问 Redis 之前先过一层布隆过滤器。如果布隆过滤器说这个短码不存在直接拦截防止缓存穿透打挂数据库。3. 如何应对热点 Key比如某个大 V 发了一条微博短链接瞬间被点爆。方案开启 Redis 的Local Cache二级缓存。在本地 Tomcat 内存中缓存极热点的短链接连网络 I/O 都省了。四、 面试标准答案模板直接背诵“针对短链接系统设计我的核心思路是‘发号器机制 Base62 编码 多级缓存策略’状态码选择采用HTTP 302确保每一笔点击流量都能经过后台实现精确的业务数据统计。生成逻辑舍弃有碰撞风险的哈希算法采用分布式号段模式生成唯一自增 ID。将 ID 进行Base62 编码6 位短码即可支撑 568 亿数据量。查询性能采用 Redis 缓存所有短码映射由于短链接具有‘只读’属性缓存命中率非常高。系统安全在接入层部署布隆过滤器拦截恶意构造的非法短码请求保护后端数据库不被穿透。存储扩展针对百亿级数据对数据库进行分库分表按短码哈希分片并配合 CDN 加速静态资源的访问。”写在最后技术面试考的从来不是你会不会用 MD5而是你对数据碰撞、存储成本、以及全链路稳定性的掌控力。能把一个简单的 ab 问题拆解成分布式 ID、缓存穿透防御、以及 HTTP 协议深度运用的系统方案这才是架构师的功底。