需求和目标
1.给一个长URL可以返回一个短URL。
2.给一个短URL，可以重定向回原长URL。
3.用户可以自己定义一个短URL后缀
4.用户可以指定这个URL的过期时间。
非功能性需求
1.高可用
2.低延迟。
3.URL不可枚举
我们假设这个功能是用在TWEET上的，TWEET假设有1亿DAU。100M。 平均每10条有1条要用到短网址。平均每人每10天发一次推文。
那么一天的短网址写有1M。
假设读是写的100倍。 那么100M的读。
所以大概读的QPS是10000 QPS，
写的QPS是100 QPS.
每天写1M个网址，假设每个网址200字节。
每天大概要的存储是200M
那么5年大概需要 10000*200M 大概是2T左右的存储。
服务
如何防止服务滥用？
这里有2点，一种是根据注册用户，根据用户来限制每天可以转换的量。
另外一种是根据发送请求的IP，来做限制。
超过这个阈值之后，一段时间内将无法使用ENCODE服务。
存储
这个存储的SCHEMA不是很明确，可以动态变化的。NOSQL+1
QPS 2者都OK
不需要事务， NOSQL+1
如果未来需要扩展的多机的考虑，那么就用NOSQL吧。
如果没有，就都可以。
表结构怎么设计。
URL表，
KEY HASH
VALUE：
origin url
create time
expire time
create user
生成短网址的算法
算法1，ID自增，由于题目要求URL不可预测，放弃这个方案
算法2，随机生成URL，数据库去重。
优点是代码简单，缺点短网址越来越多会变得越来越慢
解决这个缺点的方案，我们可以在离线的时候，预先获得一批KEY放进内存的一个POOL里。这样生成的时候，就从这个池子里随机取一个。就不会重复了。
优化
首先说性能。
因为这个是读多写少，很容易想到我们可以缓存。
我们可以把热数据缓存进去。根据LRU策略来获得。我们
优化服务器的访问速度，我们可以根据DNS解析，不同地区的用户从而分配到更近的服务器。
这个可以用LB来做。
SCALE的问题，如果一台机器搞不定了，如何扩展。
我们可以在SHORT URL的最后一位字母上多加一个字母，表示SHARDING到哪台服务器上。
这样我们根据 SHORT URL反找LONG URL，就可以直接知道去哪台服务器了。
还有什么可以优化的吗
我们可以对URL本身来区分这是属于哪个国家，有些网址属于中国访问比较多。我们就放到中国的服务器。
所以我们可以根据地域信息再来进行SHARDING。我们需要维护一个网址-》国家的表。随后分配那些在中国的服务器的SHARDING ID到中国的池子。
我们在生成一位的SHARDING位的时候，就从池子里挑一个。
如何清理过期的数据
主动清理是比较消耗资源的。我们可以使用惰性删除。就是用户访问过期URL的时候，我们在这个时候删除，然后返回给用户错误。
如何实现自定义URL
用户发送一个自定义URL，我们尝试去获得LONG URL，如果失败，就插入新的组合，如果成功。则返回用户错误信息。
