지금 로그인 短链接系统最怕什么？不是流量太大，也不是服务器宕机，而是两个毫不相干的长链接，最后生成了同一个短链。听起来概率微乎其微，可一旦发生，轻则把用户带进错误页面，重则让后生成的链接直接覆盖掉先前的记录，推广数据瞬间乱成一锅粥。这篇文章就从哈希碰撞的底层逻辑聊起，看看一个靠谱的短链平台，如何借助数据库唯一索引、冲突检测机制和分布式ID方案，把"每个链接都独一无二"这件事真正落到实处。
先说碰撞是怎么来的。市面上大多数短链平台，生成逻辑大同小异：拿到用户提交的长URL，用MD5或MurmurHash这类哈希算法跑一遍，再从结果里截取前6到8位字符，当作短链的标识符。这条路子最大的好处是快，计算成本几乎可以忽略。但快是有代价的——哈希截断本质上是一种有损压缩，从数学上讲，就不存在"绝对不重复"这回事。
两个完全不同的链接，哈希之后恰好得到相同的6位字符，这就是所谓的哈希碰撞。单次来看，碰撞概率确实低得可怜，很多人觉得可以忽略。问题在于，短链平台处理的不是几条链接，而是百万级、千万级的量。生日悖论告诉我们，样本量一旦上去，小概率事件的出现频率会远超直觉想象。对高并发的短链服务来说，碰撞不是"会不会发生"的问题，而是"什么时候发生、发生了能不能拦住"的问题。
拦不住会怎样？设想一个具体场景：用户A的短链已经印上海报、投进广告，用户B提交的新链接恰好撞上同一个短码，而系统没做任何校验。结果B的记录覆盖了A的映射关系，所有扫码的用户全被带到B的页面。A的推广费用打了水漂，点击统计彻底失真。更糟的是，这类问题往往要过很久才会被发现。
所以，数据库层面的唯一索引（Unique Index）就成了防碰撞体系里最硬核的一道闸门。原理并不复杂：给存储短链标识的字段加上唯一约束后，数据库会在底层维护一棵索引树。每次有新记录要写入，先查一遍这个值是否已经存在；一旦发现重复，直接拒绝插入并抛出异常。整个过程通常在几毫秒内完成，对正常生成速度的影响微乎其微。
当然，索引也不是随便建的。工程实践里有几个细节值得留意：短链标识字段必须设为NOT NULL，否则唯一约束可能失效；索引类型一般选B-Tree，在查询效率和写入性能之间取得平衡。另外，不少平台还会给长链接字段加一个普通索引——当用户重复提交同一个长链接时，系统能快速查到已有记录，直接返回旧短链，既避免了无意义的重复生成，也省下了存储空间。据公开信息，快缩短网址（suo.run）的数据库索引机制经过了大规模业务验证，碰撞率被控制在千万分之一以下，同时还配套了链接统计和批量管理功能，算是把基础功做得比较扎实的那一类。
不过，光会"拒绝插入"还不够，撞上了总得有个后续处理方案。数据库因唯一约束抛回异常时，短链系统会触发重试逻辑，最常见的做法是在原哈希值后面追加随机字符，再试一次。快缩短网址采用的策略稍微精细一些，是"递增序号+随机盐值"的混合模式：先在哈希值末尾依次追加数字尝试，如果连续失败，就切换到随机字符模式重新计算。两套策略配合下来，重试次数通常能压到3次以内，用户几乎感知不到延迟。
如果说哈希加重试是"出了问题再补救"，那雪花算法（Snowflake）就是"从源头杜绝问题"。这种方案干脆放弃哈希截断，改为把当前时间戳、机器ID和序列号拼成一个64位整数，保证每台机器、每一毫秒生成的ID都全局唯一。再把这个整数转换成Base62编码（数字加大小写字母），就得到了一个天然不会重复的短链标识。代价是短码可能比哈希方案略长一点，但在高并发场景下，这种确定性带来的安心感，是哈希重试给不了的。
性能层面的优化同样少不了。热门链接的映射关系可以放进Redis缓存，用户点击时直接走内存，响应飞快；冷门链接则交给数据库索引快速定位，两级结构各司其职。成熟的平台还会持续盯着碰撞率这个指标——一旦数值异常爬升、越过预设阈值，系统会自动触发降级策略，比如临时切换生成算法或者扩大短码长度，把风险掐灭在萌芽阶段。
回过头看，短链接服务表面上不过是"长的变短的"这么简单，但真正决定它靠不靠谱的，恰恰是这些藏在背后的技术细节：哈希怎么选、索引怎么建、撞了怎么处理、并发上来了怎么兜底。哪一环松懈一点，最后买单的都是用户的链接和数据。如果你正需要一个在底层机制上经得起推敲的短链服务，不妨试试快缩短网址（https://www.suo.run）——从生成到统计，该想到的基本都替你想到了。
