一 应用场景

   短网址也称短链接、短链。由于短信、微博等平台，对于内容有长度限制，过长的url不适合直接在微信、短信等平台直接发送原始地址，需要缩短长度。转换后的短网址用于消息发送，也可以避免过多的无用信息影响用户体验。

二 短网址技术方案选择

2.1 短网址长度

微博的短网址服务用的是长度为7的字符串，这个字符串可以看做是62进制的数，那么最大能表示62^7=3521614606208；

现代的web服务器（例如Apache, Nginx）大部分都区分URL里的大小写了，所以用大小写字母来区分不同的URL是没问题的。

趣课多业务，用户按照百万量级，每个用户会使用到100个不同链接（报名、课程...）估算，需要预留1亿url，上面的数字为300亿，足够支撑。

决策：长度不超过7的字符串，由大小写字母加数字共62个字母组成

2.2 一对一还是一对多映射？

一个长网址，对应一个短网址，还是可以对应多个短网址？ 这也是个重大选择问题

一般而言，一个长网址，在不同的地点，不同的用户等情况下，生成的短网址应该不一样，这样，在后端数据库中，可以更好的进行数据分析。如果一个长网址与一个短网址一一对应，那么在数据库中，仅有一行数据，无法区分不同的来源，就无法做数据分析了。

以这个7位长度的短网址作为唯一ID，这个ID下可以挂各种信息，比如生成该网址的用户名，所在网站，HTTP头部的 User Agent等信息，收集了这些信息，才有可能在后面做大数据分析，挖掘数据的价值。短网址服务商的一大盈利来源就是这些数据。

决策：一对多

2.3 如何计算短网址

现在我们设定了短网址是一个长度为7的字符串，如何计算得到这个短网址呢？

最容易想到的办法是哈希，先hash得到一个64位整数，将它转化为62进制整，截取低7位即可。但是哈希算法会有冲突，如何处理冲突呢，又是一个麻烦。这个方法只是转移了矛盾，没有解决矛盾，抛弃。

决策：分布式发号器(Distributed ID Generator)

2.4 如何存储

关系型数据库/k-v数据库

2.5 301还是302重定向

301是永久重定向，302是临时重定向。短地址一经生成就不会变化，所以用301是符合http语义的。但是如果用了301， Google，百度等搜索引擎，搜索的时候会直接展示真实地址，那我们就无法统计到短地址被点击的次数了，也无法收集用户的Cookie, User Agent 等信息，这些信息可以用来做很多有意思的大数据分析，也是短网址服务商的主要盈利来源。

决策：302重定向

新浪微博的短网址http://t.cn/RX2VxjI 请求过程：

2.6 预防攻击

如果一些别有用心的黑客，短时间内向TinyURL服务器发送大量的请求，会迅速耗光ID，怎么办呢？

首先，限制IP的单日请求总数，超过阈值则直接拒绝服务。

光限制IP的请求数还不够，因为黑客一般手里有上百万台肉鸡的，IP地址大大的有，所以光限制IP作用不大。

可以用一台Redis作为缓存服务器，存储的不是 ID->长网址，而是 长网址→ID，仅存储一天以内的数据，用LRU机制进行淘汰。这样，如果黑客大量发同一个长网址过来，直接从缓存服务器里返回短网址即可，他就无法耗光我们的ID了。

决策：考虑到实际场景，短网址生成服务仅对内部用户使用，并不会对外开放，这点通过访问的网络连通性设置、授权来实现控制。一期仅允许内网通过授权码鉴权访问。

2.7 短网址有效期 与 是否需要回收？

暂不考虑，运行一段时机后，在发号机制中增加回收号码的再次使用策略即可，另外也可以考虑短网址增加属性为短期有效和永久有效等，配合生成回收机制

2.8 扩容方案

提升接口并发能力：

   增加机器，从号源服务/模块获取号段，然后各应用实例独立计算短网址地址；

存储能力:

   数据库分库分表

增加短网址容量：

   增加位数，每增加一位 可用短网址数量*62

   增加域名，可用短网址地址 翻倍；

三 实现方案

3.1 流程&架构设计

3.1.1 客户端请求

3.1.2 服务组成：

1、短网址生成服务

2、发号器服务/模块

3、短网址查询/重定向服务

3.1.3 存储组成：

1、应用服务器本地缓存

2、分布式缓存

3、db

3.2 各服务详细设计

3.2.1 发号器服务/模块

根据频率预估，每次取1000个号；

应用服务：

1、在本地存储号段的起始、终止位置，以及当前已生成到了第几个号源 存储位置：内存，应用重启或异常终止时丢失

2、请求生成短网址的原始链接，判断是否已存在，如果存在直接返回；

3、号转化为字符串，拼接域名，生成短网址

4、存储映射关系，写入db