短链介绍
把普通网址，转换成比较短的网址。比如：http://t.cn/RlB2PdD 这种，在微博这些限制字数的应用里。好处不言而喻。短、字符少、美观、便于发布、传播。
百度短网址 http://dwz.cn/
谷歌短网址服务 https://goo.gl/ 号称是最快的
使用场景
比如短信有字数限制啊，长链传播麻烦啊。
短链跳转原理解析
当我们在浏览器里输入 http://t.cn/RlB2PdD 时
- DNS首先解析获得 http://t.cn 的
IP地址 - 当
DNS获得IP地址以后（比如：74.125.225.72），会向这个地址发送HTTPGET请求，查询短码RlB2PdD - http://t.cn 服务器会通过短码
RlB2PdD获取对应的长 URL - 请求通过
HTTP301转到对应的长 URL https://m.helijia.com 。
为啥是302
301 是永久重定向，302 是临时重定向。短地址一经生成就不会变化，所以用 301 是符合 http 语义的。同时对服务器压力也会有一定减少。
但是如果使用了 301，我们就无法统计到短地址被点击的次数了。而这个点击次数是一个非常有意思的大数据分析数据源。能够分析出的东西非常非常多。所以选择302虽然会增加服务器压力，但是我想是一个更好的选择。
短链实现原理
发号器 + 62进制转换。
给每一个过来的长地址，发一个号即可，小型系统直接用mysql的自增索引就搞定了。如果是大型应用，可以考虑各种分布式key-value系统做发号器。不停的自增就行了。第一个使用这个服务的人得到的短地址是http://xx.xx/0 第二个是 http://xx.xx/1 第11个是 http://xx.xx/a 第依次往后，相当于实现了一个62进制的自增字段即可。
为什么用62进制？而不是64进制
1. 62进制转换是因为62进制转换后只含数字+小写+大写字母。而64进制转换会含有/,+这样的符号（不符合正常URL的字符）
2. 10进制转62进制可以缩短字符，如果我们要6位字符的话，已经有560亿个组合了。（62^6 = 56800235584）
发号器顺序生成自增ID不安全
构造 62进制的字母不要按顺序排列。
用户自定义短链
比如，我们用mysql去存储短链-长链的对应关系，再增加一个字段：短链生成方式（1：系统自动；2：用户自定义）
如果有用户自定义过短码，把它的类型标记自定义。
每次根据 id 计算短码的时候，如果发现对应的短码被占用了，就从类型为自定义的记录里随机选取一条记录，用它的 id 去计算短码。
这样既可以区分哪些长连接是用户自己定义还是系统自动生成的，还可以不浪费被自定义短码占用的 id。
如何保证同一个长地址，每次转出来都是一样的短地址
其实也没必要存，就算存，可以存“最近”生成的长对短的一个对应关系。注意是“最近”，也就是说，我并不保存全量的长对短的关系，而只保存最近的。比如采用一小时过期的机制来实现LRU淘汰。保存热门短链即可。
如何保证发号器的大并发高可用
2个发号器，1个发单号，一个发双号。依此类推。
一些不好的方案
(X) 实现算法将长链变为短链
实现一个算法，将长地址转成短地址。实现长和短一一对应。然后再实现它的逆运算，将短地址还能换算回长地址。但不行！！！
不要逆运算
和上面一样，也找一个算法，把长地址转成短地址，但是不存在逆运算。我们需要把短对长的关系存到DB中，在通过短查长时，需要查DB。也不行！！！
也能会存在hash碰撞。
就算碰撞，在后面加1，2，3
用一个hash算法，我承认它会碰撞，碰撞后我再在后面加1，2，3不就行了。 ok，这样的话，当通过这个hash算法算出来之后，可能我们会需要做btree式的大于小于或者like查找到能知道现在应该在后面加1，2，或3，这个也可能由于输入的长地址集的不确定性。导致生成短地址时间的不确定性。
随机生成一个短地址
随机生成一个短地址，去查找是否用过，用过就再随机，如此往复，直到随机到一个没用过的短地址。