引用、参考：
什么是短链接
表示较短的URL（是不是废话？....）
为什么需要短链接
- 不同的浏览器对URL的长度有不同的限制，当URL长度超出极限，可能无法正常得到服务或资源
- 较短的链接更为美观（也是废话...）
- 便于统计。为什么呢？
系统设计
目标：将较长的链接映射到较短的链接，如domain/resource_abcdedfwefwf...映射到 domain/3a6f7A。一般对于大部分应用，映射到6位已经足够了，每位可以取[a-z A-Z 0-9]，共26+26+10=62种，可以表示62^6=560亿个链接或资源。当然，你也可以选择位数稍多一点。
映射机制
- 对每个长链接，使用一个小于560亿的整数标记。小型系统中，小型系统直接用mysql的自增索引就搞定了。只要做一个发号控制器，负责根据序号找到长链接和为长链接生产序号。
- 如何将序号映射到六位？只需进行一个10进制到62进制的转换即可。因此，控制器需要提供一个进制转换工具。
- 综上，当申请一个资源domain/3a6f7A，先由控制器将3a6f7A从16进制转为10进制，在根据数据索引找到真正的URL，再去申请资源domain/resource_abcdedfwefwf...
分布式
如果只有一个发号控制器，对于系统可能形成单点性能瓶颈和单点故障问题。
解决方法：使用多个发号控制器。" 我们是否可以实现两个发号器，一个发单号，一个发双号，这样就变单点为多点了？依次类推，我们可以实现1000个逻辑发号器，分别发尾号为0到999的号。每发一个号，每个发号器加1000，而不是加1。这些发号器独立工作，互不干扰即可。而且在实现上，也可以先是逻辑的，真的压力变大了，再拆分成独立的物理机器单元。1000个节点，估计对人类来说应该够用了。如果你真的还想更多，理论上也是可以的。"
存储
各种DB，CACHE都可以用....，你喜欢（又是废话）。
跳转用301还是302
- 301是永久重定向，302是临时重定向。短地址一经生成就不会变化，所以用301是符合http语义的。同时对服务器压力也会有一定减少。
- 如果使用了301，我们就无法统计到短地址被点击的次数了。而这个点击次数是一个非常有意思的大数据分析数据源。能够分析出的东西非常非常多。
短链接不够用或者
虽然我们的短链接可以表示560亿个资源，貌似很多，但是对于大型系统，如银行，搜索引擎等等，还是非常少的。但是我们可以知道一个现实，就是，某一个较短的时间段，被请求的资源数是有限的，比如，10分钟内，被访问的微博URL数目不会超过560亿。当然这个时间段和上限你可以根据实际情况调整。
解决：
- 既然6位短链接不够用，那可以多使用几位，比如8位，大概等于560亿*62*62.
- 但是，总是有限的。”可以用key-value存储，保存“最近”生成的长对短的一个对应关系。注意是“最近”，也就是说，并不保存全量的长对短的关系，而只保存最近的。比如采用一小时过期的机制来实现LRU淘汰。“所以当一个地址被频繁使用，那么它会一直在这个key-value表中，总能返回当初生成那个短地址，不会出现重复的问题。如果它使用并不频繁，那么长对短的key会过期，LRU机制自动就会淘汰掉它。当然，这不能保证100%的同一个长地址一定能转出同一个短地址，比如你拿一个生僻的url，每间隔1小时来转一次，你会得到不同的短地址。
思考：如果采用LRU，有一些短链接会被淘汰；如果短链接仍然使用自增方式，可能会溢出（超出560亿）。如何解决该问题？
限定key-value表中永远不会超过100亿条记录，超过就根据LRU进行淘汰；被淘汰的短链接放在回收器中；当序号几近溢出或者已使用的最大序号超过某个阈值，就使用回收器中的曾被使用或的短链接，不再使用自增来产生序号。