3.如何设计一个短链系统？
1.概述
在社区类产品甚至短信中，我们常常可以看到加入了诸如https://dwz.win/auQx几位编码的短链接。虽然很大一部分因为可能是社交类媒体的文本长度限制，但将长链接转成短链，还有其它几大优势：
- 短链接一般六到八位路径地址，方便对外使用
- 短链接支持定向，也可随时修改重定向源地址
- 简化二维码，提高二维码的识别率（二维码复杂度和原始信息大小正相关）
常用的短链接服务商：
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 算法进行淘汰，同时关注缓存三大问题。