怎么样设计短链接系统？-Toy模板网

这篇具有很好参考价值的文章主要介绍了怎么样设计短链接系统？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

短链接是什么？

短链接，顾名思义就是短的链接，能将很长的链接转化为短链接，并且能由短链接指向原来长链接所指向的地方。

为什么需要短链接？

最简单直接的方式其实是对长链接生成hash。然而这种方法却存在问题

为了解决无法逆转的问题可以通过储存对应hash与链接的映射来实现，并且通过bloom filter来筛选出碰撞的hash，从而在后面添加字符来达到唯一性，从而解决hash碰撞

即使如此，这种方法仍然存在问题

储存映射。不仅占用了储存空间，还给系统增加了额外复杂度
碰撞添加字符到达唯一性。如何添加成为了问题，如果是通过一个id，递增添加，那么在高并发情况下，这可能会成为性能瓶颈（引入加锁全局id，锁会成为瓶颈；直接递增，那么一次次判断递增后的短链接是否存在也会成为瓶颈）

尽管如此，在长链接并不是特别多或者不在乎碰撞的情况下，hash方法是一个简单易行的方案

为每一个长链接唯一编号。本方法优势明显，不存在碰撞问题，也不存在为了解决碰撞，而一直递增以达到不重复的性能损失问题。但仍然存在一些问题

分配编号是串行的。

对于redis来讲，单机能支撑10w qps，性能相当高，只是要考虑到持久化；

mysql自增机制相对来讲性能较差，但是比较简单，对于多数业务来讲完全够用
仍然需要额外空间储存对应关系
在分布式系统中需要更多处理来保证唯一

这与分布式主键的处理方法一致，比如说不同子系统之间不同的初始值以及递增步伐、雪花算法、号段模式、uuid等

首先要搞明白用什么类型来储存长短链接。

长链接显然不能用整数类型进行存储，只能用字符串

而对于短链接，用整数类型，储存空间更小，甚至能范围查询（虽然这样生成的唯一编号并没有太大的实际意义，用到范围查询的可能性并不高），但由于实际使用中用的一般是62进制（10个数字+2*26字母），所以还需要进行转换，如果采用字符串则少了转换过程。总的来说，采用整数类型优势更为明显。

在长短链接之后，最好还是考虑一下升级问题。比如最开始采用了mysql生成唯一编号，随着业务发展无法充分满足需求要切换到redis生成的方式，但是mysql生成又不能直接停下，因为还要生成唯一编号。这种情况下可以添加新字段source来区别生成id来源

如果要对短链接生成、访问进行追踪数据，那么储存生成时间、用户、ip等信息的字段也要添加

此外考虑到基本场景是根据短链接查询长链接，因此短链接最好建立索引。那么短链接是否可以干脆作为主键呢？一般而言，短链接是不会出现重复的，并且也不会超出最大整数范围，那么为了加快查询，添加为主键也不失为一个好的方法

取决于是否要追踪数据。如果需要分析访问访问特征数据，比如访问该链接用户、ip等，那么可以将信息编码到短链接中

如果根本不需要追踪或者根本不需要通过这种方式追踪，那么就并不需要长短链接一对多生成了

经典老办法——加缓存。

安全措施：限制频率，屏蔽用户、ip等
id稀疏：不严格按照1进行递增
生成特别的id：比如采用递增id+hash(id+key)这样的方法
内外分离：内部采用递增，外部生成难以找到规律的id（比如随机、hash、加密等），并储存内外映射
不采用递增编号：比如uuid、雪花算法等
业务分析是否是个问题：如果本来就是公开的内容，那么就算被遍历又怎么了；如果是非公开的内容，那么添加身份认证是否会更好呢？毕竟即使采用其他方法，攻击者无法通过遍历获取到内容，但也有可能从其他渠道知道链接