一些问题

1.如何存储对对应关系
2.如何应对短时间大量的提交
3.是否应该保证一个长网址对应一个短网址
4.短网址Id如何获得？

思考

1.关于存储，首先是不应该考虑关系型数据库的。最合适的应该是KV型数据库，支持更快的数据查询，并且关系型数据库单表数量有限制。
我的系统中采用的是Redis，采用Hsh来存储，每个hash支持40亿左右的字段。
根据短网址的结尾，有62种不同的字符串，作为key，然后以短网址为field，既能保证存储量，也能保证速度。

2.可以采用另一个Redis，以原始Url为Key，短网址为value，采用LRU淘汰机制。存储最近一段时间内生成的短网址，如果出现恶意提交，或是热门原始Url，能保证空间不被耗光。

3.根据需求，如果需要对数据进行收集，应该使用一对多，保证能够收集到短网址提交者的数据。而针对2情况中的短时间多次提交等，则根据需求，调整Redis存储周期。

4.我采用的是snowflake算法。生成全局Id，并且通过62进制转换，获取到对应的短网址。也可以根据需求，使用Redis来发号，例如两个实例，一个发单号，一个发双号。