字节三面:如何设计一个高性能短链系统?
共 5960字,需浏览 12分钟
·
2023-10-12 12:12
什么是短链?为什么要用短链?
-
链接变短,在对内容长度有限制的平台发文,可编辑的文字就变多了。比如微博限定了只能发 140 个字,如果一串长链直接复制上去就没地方再写其他文字了 -
大家接受各种短信的时候,能发现大部分链接都是短链形式,因为一般短信发文有长度限度,如果用长链,一条短信很可能要拆分成两三条发,相应的成本也就增加了 -
使用短链在排版上更加美观
短链跳转的基本原理
-
301,代表 永久重定向:第一次请求拿到长链接后,下次浏览器再去请求短链的话,不会向短链服务器请求了,而是直接从浏览器的缓存里拿,这样的话短链服务器就无法获取到短链的点击数了,不利于数据分析,所以我们一般不采用 301 -
302,代表 临时重定向:每次去请求短链都会去请求短链服务器(除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存),这样便于短链服务器统计点击数
生成短链的两种方法
方法 1:哈希算法
如何让短链更短
如何解决哈希冲突
-
如果没有找到相同的短链,这就表明这个新生成的短链没有冲突。于是我们就将这个短链返回给用户,然后将这个短链与原始网址之间的对应关系,存储到 MySQL 数据库中
-
如果在数据库中找到了相同的短链,那也并不一定说明就冲突了。我们先从数据库中将这个短链对应的原始网址取出来:
-
如果数据库中的原始网址,跟我们现在正在处理的原始网址是一样的,这就说明已经有人请求过这个原始网址的短链了。我们就可以拿这个短链直接用。
-
如果数据库中记录的原始网址,跟我们正在处理的原始网址不一样,那就说明哈希算法发生了冲突。不同的原始网址,经过计算,得到的短链重复了。这个时候,我们可以给原始网址拼接一串特殊字符,比如
DUPLICATED
,然后再重新计算哈希值,两次哈希计算都冲突的概率,显然是非常低的。假设出现非常极端的情况,又发生冲突了,我们可以再换一个拼接字符串,比如OHMYGOD
,再计算哈希值。然后把计算得到的哈希值,跟原始网址拼接了特殊字符串之后的文本,一并存储在 MySQL 数据库中。当用户访问短链的时候,短链服务先通过短链,在数据库中查找到对应的原始网址。如果原始网址有拼接特殊字符(这个很容易通过字符串匹配算法找到),就先将特殊字符去掉,然后再将不包含特殊字符的原始网址返回给浏览器。
如何优化性能
-
第一个 SQL 语句是通过短链查询短链与原始网址的对应关系 -
第二个 SQL 语句是将新生成的短链和原始网址之间的对应关系存储到数据库
方法二:ID 生成器
相同的原始网址可能会对应不同的短链
-
第一种处理思路是不做处理。听起来有点匪夷所依,但实际上,相同的原始网址对应不同的短链,这个用户是完全可以接受的。在大部分短链的应用场景里,用户只关心短链能否正确地跳转到原始网址。至于短链长什么样子,他其实根本就不关心。
-
第二种处理思路是拿原始网址在数据库中查找,看数据库中是否已经存在相同的原始网址了。如果数据库中存在,那我们就取出对应的短链,直接返回给用户。
不过,这种处理思路有个问题,我们需要给数据库中的短链和原始网址这两个字段,都添加索引。短链上加索引是为了提高用户查询短链对应的原始网页的速度,原始网址上加索引是为了加快刚刚讲的通过原始网址查询短链的速度。这种解决思路虽然能满足 “相同原始网址对应相同短链” 这样一个需求,但是是有代价的:一方面两个索引会占用更多的存储空间,另一方面索引还会导致插入、删除等操作性能的下降。
如何实现高性能的 ID 生成器
可能不是很好理解,这里类比下 “无锁的并发生产者 - 消费者模型”: 对于生产者来说,它往队列中添加数据之前,先申请可用空闲存储单元,并且是批量地申请连续的 n 个(n≥1)存储单元。当申请到这组连续的存储单元之后,后续往队列中添加元素,就可以不用加锁了,因为这组存储单元是这个线程独享的。不过,申请存储单元的过程还是需要加锁的。 对于消费者来说,处理的过程跟生产者是类似的。它先去申请一批连续可读的存储单元(这个申请的过程也是需要加锁的),当申请到这批存储单元之后,后续的读取操作就可以不用加锁了。
往期推荐