短链接

短链接

使用短链接 即用一个短的链接指向长的链接 从而满足字数的要求

定义一个URL映射算法，将长的URL映射到短的URL，使用数据库或者redis缓存存储映射关系，实现映射算法。其中关键部分在于映射算法.

hash算法存在hash碰撞的问题

现在用的比较多的是发号器+62进制编码

301还是302重定向

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

如何保证发号器的大并发高可用

实现两个发号器，一个发单号，一个发双号，这样就变单点为多点了？依次类推，我们可以实现1000个逻辑发号器，分别发尾号为0到999的号。每发一个号，每个发号器加1000，而不是加1。

如何实现同一个长地址多次转换，出来还是同一个短地址

用key-value存储，保存“最近”生成的长对短的一个对应关系。注意是“最近”，也就是说，我并不保存全量的长对短的关系，而只保存最近的。比如采用一小时过期的机制来实现LRU淘汰。

这样的话，长转短的流程变成这样： 1 在这个“最近”表中查看一下，看长地址有没有对应的短地址 1.1 有就直接返回，并且将这个key-value对的过期时间再延长成一小时 1.2 如果没有，就通过发号器生成一个短地址，并且将这个“最近”表中，过期时间为1小时

所以当一个地址被频繁使用，那么它会一直在这个key-value表中，总能返回当初生成那个短地址，不会出现重复的问题。如果它使用并不频繁，那么长对短的key会过期，LRU机制自动就会淘汰掉它。

当然，这不能保证100%的同一个长地址一定能转出同一个短地址，比如你拿一个生僻的url，每间隔1小时来转一次，你会得到不同的短地址。但是这不会影响太多性能