短链是基于 HTTP 的 301/302 状态码进行工作的；即浏览器通过短链访问短链服务，短链服务通过短链得知真实长链，以重定向的方式返回真实地址给浏览器，浏览器接收到重定向状态码，便对真实地址进行重定向访问，从而达到通过短链访问长链地址的作用
301永久重定向- 用户请求短链，短链系统返回长链地址，并告知 301 状态码。浏览器获得真实长链后，缓存起来，下次用户再次请求，就直接去缓存获取，而不再走短链系统了
302临时重定向- 用户请求短链，短链系统返回长链地址，并告知 302 状态码。浏览器得知是临时重定向，所以之后每次请求都再次向短链服务获取真实地址
301 和 302 可以根据具体的业务场景进行选择。比如我们需要进行活动数据分析，那么建议使用 302 状态码，这样可以获得到更为真实的活动数据
http://snailmann.link/a/IW10D- 短链域名
http://snailmann.link/a/ - 短链 key
IW10D
- 短链域名
第二部分的短链 key 则是我们需要重点设计的部分，即我们如何为每一个短链生成一个唯一的 key
哈希算法需要解决几个问题
- 哈希冲突如何解决？
- 哈希冲突时存在并发问题，如何解决并发性能？
- 哈希值因为均匀分布，导致大部分哈希值过大，短链过长，如何压缩？
- 自增序列算法理论上，不会出现冲突问题，可以很好的避免了哈希冲突
- 但是自增序列也导致了无法从原始链接直接查询短链, 需要新的映射表来辅助查询
需求
- 支持写入长链，返回短链给用户
- 当用户访问短链，服务应该 redirect 到长链地址
- 短链需要有默认的过期时间，支持用户注册时，控制过期时间
- 服务需要高可用，保证服务可用率 > 99.9%
- 读请求时延尽可能低
考量因素
- 长短链对应关系
- 存储选型与成本
- 数据分区
- 容量/带宽/并发预估
- 短链生成算法
- 过期数据清理
长短链映射关系？ 长链与短链之间的关系是，一对一还是一对多？
- 个人认为一对多即可，很多时候我们需要根据短链进行活动统计，如果该长链在不同的场景需要分别统计，那么一对一的话，就不方便区分场景统计了