短地址设计思想
场景
短链接服务就是将一段长的URL转换为短的URL，比如利用新浪微博的短链接生成器，可将一段长的URL（http://blog.csdn.net/poem_qianmo/article/details/52344732）转换为一段短的URL（http://t.cn/RtFFvic），用户通过访问短链接即可重定向到原始的URL。
整个交互流程如下：
- 用户访问短链接：http://t.cn/RtFFvic
- 短链接服务器t.cn收到请求，根据URL路径RtFFvic获取到原始的长链接：http://blog.csdn.net/poem_qianmo/article/details/52344732
- 服务器返回302状态码，将响应头中的Location设置为：http://blog.csdn.net/poem_qianmo/article/details/52344732
- 浏览器重新向http://blog.csdn.net/poem_qianmo/article/details/52344732发送请求
- 返回响应
设计要点
-
短链接生成算法
(1)利用放号器，初始值为0，对于每一个短链接生成请求，都递增放号器的值，再将此值转换为62进制（a-zA-Z0-9），比如第一次请求时放号器的值为0，对应62进制为a，第二次请求时放号器的值为1，对应62进制为b，第10001次请求时放号器的值为10000，对应62进制为sBc。
(2)将短链接服务器域名与放号器的62进制值进行字符串连接，即为短链接的URL，比如：t.cn/sBc。
-
重定向过程
生成短链接之后，需要存储短链接到长链接的映射关系，即sBc -> URL，浏览器访问短链接服务器时，根据URL Path取到原始的链接，然后进行302重定向。映射关系可使用K-V存储，比如Redis或Memcache。
优化方案
-
算法优化
采用以上算法，对于同一个原始URL，每次生成的短链接是不同的，这样就会浪费存储空间，因为需要存储多个短链接到同一个URL的映射，如果能将相同的URL映射成同一个短链接，这样就可以节省存储空间了。
（1）方案1：查表
每次生成短链接时，先在映射表中查找是否已有原始URL的映射关系，如果有，则直接返回结果。很明显，这种方式效率很低。
（2）方案2：使用LRU本地缓存，空间换时间
使用固定大小的LRU缓存，存储最近N次的映射结果，这样，如果某一个链接生成的非常频繁，则可以在LRU缓存中找到结果直接返回，这是存储空间和性能方面的折中。
-
可伸缩和高可用
如果将短链接生成服务单机部署，缺点一是性能不足，不足以承受海量的并发访问，二是成为系统单点，如果这台机器宕机则整套服务不可 用，为了解决这个问题，可以将系统集群化，进行“分片”。
在以上描述的系统架构中，如果发号器用Redis实现，则Redis是系统的瓶颈与单点，因此，利用数据库分片的设计思想，可部署多个发号器实例，每个实例负责特定号段的发号，比如部署10台Redis，每台分别负责号段尾号为0-9的发号，注意此时发号器的步长则应该设置为10（实例个数）。
另外，也可将长链接与短链接映射关系的存储进行分片，由于没有一个中心化的存储位置，因此需要开发额外的服务，用于查找短链接对应的原始链接的存储节点，这样才能去正确的节点上找到映射关系。
