短链接问题？

• 短链接
  如今短信中短链接十分流行，众所周知，短链接代替了原本冗长的网页链接，用户体验更好。那短链接背后怎么实现呢？

• 原理
  如美团短信：
  【美团外卖】最高10元外卖红包送给你，考试期间提供美食多多！ dpurl.cn/6N2zIIG 回TD退订
  打开上面的短网址，其会通过重定向的方式如 302 跳转到一个页面网址，相对这个短网址来说，所对应的网址更长（https://activity.waimai.meituan.com/static/html/wmdownload.html）的多。
  短链接地址的构成是26英文字母的大小写加0-9数字。10数字+26大写字母+26小写字母=62。通过发号策略，给每一个过来的长地址，分一个号即可，小型系统直接用mysql的自增索引就搞定了。如果是大型应用，可以考虑各种分布式key-value系统做发号器。不停的自增就行了。第一个使用这个服务的人得到的短地址是http://xxx.xxx/0， 第二个是 http://xxx.xxx/1 ，第11个是 http://xxx.xxx/a 第依次往后到大写Z，相当于实现了一个62进制的自增字段。

• 问题1：并发量高怎么处理
  很容易我们联想到分布式。这里我们可以用下面这个方法，比如我们分成两个机器，一个机器存尾号是单数的短链接id，一个机器存尾号是双数的短链接id。比如单号机器第一次存1，自增的时候加2，下次就是3。同理，如果我们使用100个机器分别存尾号0-99，每次每台机器自增100，实现了高并发的处理。

• 问题2：跳转用301还是302？
  首先两者都是重定向的HTTP状态码。301 redirect: 301 代表永久性转移(Permanently Moved)，302 redirect: 302 代表暂时性转移(Temporarily Moved )。如果使用了301，我们就无法统计到短地址被点击的次数了，使用302可以统计到流量。

• 问题3：比如我们用单双号的方法存储短链接id，如果存储单号的机器宕机怎么处理？
  我们可以设计主从模式，比如单节点用两个机器，两个机器的数据同步，主节点宕机之后从节点升级为主节点。