短链接服务的原理和实现

1 概述

在社区类产品甚至短信中，我们常常可以看到加入了诸如https://dwz.win/auQx几位编码的短链接。虽然很大一部分因为可能是社交类媒体的文本长度限制，但将长链接转成短链，还有其它几大优势：

• 短链接一般六到八位路径地址，方便对外使用
• 短链接支持定向，也可随时修改重定向源地址
• 简化二维码，提高二维码的识别率（二维码复杂度和原始信息大小正相关）

常用的短链接服务商：

• 新浪短链接
• SUO短链接
• 百度短链接

2 实现原理

再浏览器中访问https://dwz.win/auQx，查看其请求过程：

1）首先浏览器通过 DNS 解析得到 dwz.win 域名的 IP 地址
2）携带短链编码 auQx 通过 IP 访问到对应的短链接服务器
3）短链服务通过短链编码 auQx 查询到系统中记录的（源）长链接
4）通过 HTTP 301 状态码重定向到对应的长链接地址

3 实现原理

再次之前，应当申请一个相当短得到域名。

由以上分析出实现短链服务可以分为两步，将长链接生成短链接，再通过短链接快速准确访问到长链接。

3.1 生成短链

生成短链接的本质是要确认一对短链接和长链接的唯一 KV 关系，也就是所以常见的生成方式有两种：Hash 和 自增 ID。

3.1.1 Hash

此方案是通过 Hash 算法将任意长度的长链接计算输出得到一个固定长度的短码。好处就是实现简单，安全性高。但缺点也显而易见，再好的 Hash 算法也无法解决碰撞问题，且随着数量的增大碰撞概率也随之增大，所以此方案难点是如何处理碰撞冲突问题。

常见处理哈希冲突方法：

• 开放定址法
• 链地址法
• 再哈希
• 公共溢出区

3.1.2 自增 ID

自增 ID 可以确保全局唯一性，且市面上已有成熟的实现方案：

• UUID
• 数据库自增
• Redis生成
• 分布式算法（如雪花）

短链接一般由大小写字母和数字组成，共有 26+26+10 = 62 个字符。在得到一个十进制 Long 型 ID 后，可以通过 62 进制转成 6 个字符。但如果仅简单使用自增ID，会带来严重的安全问题，因为生成的短链接可以猜测和遍历。

提高安全性：

• 可以对 ID 进行跳码计算，防止猜测
• 结合长链接等信息进行安全位计算，并打乱顺序，防止遍历
• 同时支持校验，防止恶意尝试直接回落 DB

3.2 数据存储

是否有必要分库分表取决于自身业务，分库分表时，可以直接对短链进行哈希，也可以增加一位库表前缀。

3.3 查询长链

从成本考虑，将数据全部放到缓存不太现实，同时加上分库分表理论也够用。如果使用缓存，可以考虑使用 LRU 算法进行淘汰，同时关注缓存三大问题。