短链接技术的本质，是用极短的字符空间承载无限长的网络地址。这项看似简单的服务，背后是一套精密的映射工程——将动辄上百字符的URL压缩为几个字母数字的组合，同时保证全球唯一、毫秒响应、高可用抗攻击。

从长到短：两种截然不同的压缩哲学

业界主流的短码生成路径分为两派。哈希派信奉"计算即定位"：对原始URL执行MD5或SHA-1运算，从生成的32位十六进制字符串中截取前6到8位。这种方法的优势在于纯粹的无状态——无需中心计数器，任何节点独立计算都能得出一致结果。但缺陷同样明显：哈希冲突不可避免，当不同长链碰撞出相同短码时，系统必须引入二次哈希或冲突解决链，复杂度陡增。

另一派则是进制转换派，也是当前工业界更偏好的方案。核心逻辑是为每条长链分配一个全局唯一的自增整数ID，再将这个十进制数字映射到62进制（0-9、a-z、A-Z）。十进制1000000在62进制下仅为"4c92"，字符长度压缩超过60%。这种方案的关键瓶颈在于ID生成器的高并发性能，Twitter早期采用Snowflake算法改造，将时间戳、机器ID、序列号嵌入64位整数，既保证趋势递增，又实现分布式环境下的无冲突生成。



数据库架构：从单表到十亿级分片

短链系统的查询模式极具特色——写操作低频（仅在生成时发生），读操作极高频（每次点击都触发），且查询条件永远是精确匹配短码。这种特性决定了存储层的设计方向：

基础版本采用单表结构，短码作为主键，原始URL以TEXT类型存储，配合过期时间与点击统计字段。当数据量突破千万级，按短码首字符分表是经典策略——"a"开头的短码落入表a，"b"落入表b，查询时直接定位目标分片，规避全表扫描。



缓存层几乎是必选项。Redis以短码为key存储长链，设置合理的TTL过期时间。热门短链的命中率可达99%以上，数据库压力骤减。更激进的架构会将短码到长链的映射直接载入内存，配合一致性哈希实现多节点数据分片，单机即可支撑数万QPS。

跳转机制：302与301的微妙抉择

用户点击短链后的跳转流程，隐藏着HTTP状态码的深层考量。302临时重定向是默认选择——服务器每次实时查询数据库，返回当前绑定的长链。这种模式的灵活性无可替代：运营人员可随时修改短链指向，用户无感知生效。但代价是每次跳转都需经过短链服务器，无法利用浏览器缓存。

301永久重定向则承诺"此地址永久变更"，浏览器会将映射关系本地缓存，后续访问直接跳转目标站点，不再请求短链服务。这对SEO权重传递更为友好，但短链一旦发布即失去修改能力。实际工程中，营销类短链普遍采用302，品牌官方短链倾向301，部分平台甚至支持动态切换策略。

安全防线：从碰撞攻击到钓鱼识别

短码空间的可枚举性天然带来安全风险。6位62进制短码的总组合数为568亿，看似庞大，但现代GPU可在数小时内完成全空间扫描。防御体系需多层布防：

生成阶段引入盐值扰动，将用户ID、时间戳、随机数混入哈希输入，使相同长链在不同时刻生成不同短码，阻断碰撞预测。访问层实施速率限制，单IP在短时间内请求过量短码时触发验证码或封禁。更前沿的系统会集成URL信誉库，对指向已知钓鱼站点或恶意软件的短链实施拦截，甚至主动替换为安全提示页面。

工业实践：Twitter的字符战争



2011年前的Twitter面临独特困境：140字符的限制下，一条包含长链的推文可能仅剩几十个字符用于正文表达。自建t.co短链体系成为战略决策——所有外链强制替换为t.co域名下的短码，不仅释放内容空间，更关键的是收回了数据主权。点击热力图、地域分布、设备类型，这些原本属于第三方短链服务商的分析维度，从此纳入Twitter的核心数据资产。t.co短码固定为23字符（含https://），无论原始URL多长，为推文排版提供了确定性预期。

动态能力的业务价值

进阶短链系统支持"不变形变"——短码发布后，后台可随时更换绑定的长链，前端二维码、印刷物料、社交分享无需任何改动。这对营销场景至关重要：A/B测试时同一短码分流至不同落地页，活动过期后短码指向新的促销页面，甚至根据用户设备、地理位置、时间段执行智能路由。这种"活码"能力将短链从静态跳转工具，升级为持续运营的数字触点。



构建自有短链服务的起点建议明确：初期采用自增ID+62进制方案保证可读性，Redis缓存支撑并发，MySQL主从架构保障数据持久。当日均生成量突破百万或跳转请求达到十万QPS时，再引入分布式ID生成、多级缓存、异地多活等复杂架构。技术的演进永远服务于业务节奏，而非超前堆砌复杂度。