自己做一个短链服务，设计思路分享！

其实实现短链服务并不是很难&＃xff0c;最主要还是需要知道一些设计思路&＃xff0c;还需要有一些基础技术知识&＃xff0c;例如&＃xff1a;哈希算法、全局发号器等。

下面一起来学习如何设计一个短链服务吧&＃xff01;

短链的价值

网址大家都知道&＃xff0c;很长的一串字符串&＃xff0c;很多时候我们还会在后面添加非常多的参数&＃xff0c;用来便于做数据统计。下面就是微信公众号一篇文章的地址&＃xff0c;可以看到其特别长&＃xff0c;估计将近有几百个字符。

https://mp.weixin.qq.com/s?__biz&＃61;MzA4MjIyNTY0MQ&＃61;&＃61;&mid&＃61;2647743787&idx&＃61;1&sn&＃61;1caec8eb1b81d6ee5dd7ba7fa05ac0f1&chksm&＃61;87ad0dadb0da84bb7beb5e4373a14e89fba1130c1bd2a51f4baa8021ec0abe496ce94603b6b4&token&＃61;894028224&lang&＃61;zh_CN#rd

我们可以用百度的短网址功能&＃xff0c;把上面的网址缩短成只有差不多 10 个字符串的长度&＃xff0c;如下所示。

http://dwz.cn/iijg

用短链代替长链&＃xff0c;有下面几个常见的好处&＃xff1a;

1. 更加简洁。 比起一长串无意义的问题&＃xff0c;只有差不多 10 个字符的字符串显然更加简洁。

2. 便于使用。 第一&＃xff0c;有些平台对内容长度有限制&＃xff08;微博只能发 140 个字&＃xff09;&＃xff0c;此时短网址就可以输入更多内容。第二&＃xff0c;我们将链接转为二维码时&＃xff0c;短链接生成的二维码更容易识别。第三&＃xff0c;有些平台无法识别特殊的长链参数&＃xff0c;转为短链就没这个问题。

3. 节省成本。 当我们需要发短信的时候&＃xff0c;短信是按照长度计费的&＃xff0c;短网址可以节省成本。

短链的原理

短链能够给我们带来这么多好处&＃xff0c;但它是怎么工作的呢&＃xff1f;

当我们输入短链时&＃xff0c;其实访问的是短链服务器的地址。短链服务器获取到对应的长链地址之后&＃xff0c;返回一个 302 的 HTTP 响应&＃xff0c;在响应中包含了长链接地址。浏览器收到响应后&＃xff0c;转而去请求长链接地址。 访问短链的整个流程如下图所示&＃xff1a;

从上面的流程中可以知道&＃xff0c;短链涉及到的技术原理主要有两点&＃xff0c;分别是&＃xff1a;HTTP 重定向和短链服务的设计。

对于 HTTP 重定向来说&＃xff0c;301 和 302 都是重定向&＃xff0c;那么到底应该用哪个呢&＃xff1f;

• 301 代表永久重定向。它表示第一次拿到长链接之后&＃xff0c;下次浏览器如果再去请求短链的话&＃xff0c;不会再向短链服务器请求了&＃xff0c;而是直接从浏览器的缓存中获取。

• 302 代表临时重定向。它表示每次请求短链都会去请求短链服务器&＃xff0c;不会从浏览器缓存中获取。微信搜索公众号&＃xff1a;Java后端编程&＃xff0c;回复&＃xff1a;java 领取资料 。

如果我们希望统计短链接的点击次数信息&＃xff0c;从而来分析活动的效果的话。那么我们就需要使用 302 重定向码&＃xff0c;这样才能获取到每次的请求数据。 一般情况下&＃xff0c;我们都是需要获取到请求的数据的&＃xff0c;因此对于短链服务都是用 302 临时重定向。

实现思路

让大家设计这样一个系统&＃xff0c;大家会有啥思路呢&＃xff1f;

我们可以先分析一下整个系统的处理流程&＃xff1a;

1. 用户访问短链生成页面&＃xff0c;输入长链字符串&＃xff0c;短链服务返回生成的短链。

2. 用户访问短链&＃xff0c;短链服务返回 302 响应&＃xff0c;用户浏览器跳转到长链地址。

如果我们要实现上面的系统流程&＃xff0c;我们大致的处理思路是&＃xff1a;

1. 生成短链。 生成短链时&＃xff0c;短链服务获取到长链&＃xff0c;随后生成一个短链&＃xff0c;并把短链与长链的映射关系保存下来&＃xff0c;最后将短链返回给用户。

2. 找到长链。 访问短链时&＃xff0c;短链服务获取到短链&＃xff0c;根据短链去获取到长链&＃xff0c;返回返回 302 响应。

根据上面的分析&＃xff0c;我们可以知道短链系统设计主要得解决如下两个问题&＃xff1a;

1. 如何根据长链生成唯一短链&＃xff1f;

2. 如何保存短链与长链的映射关系&＃xff1f;

对于第 2 点&＃xff0c;保存短链与长链的映射关系&＃xff0c;考虑到持久性的问题&＃xff0c;我们肯定需要落库&＃xff0c;所以使用 MySQL 表保存即可。如果有需要的话&＃xff0c;可以在 MySQL 前做一层缓存。因此第 2 点相对来说比较简单。

对于第 1 点&＃xff0c;我们有 2 个思路生成一个唯一短链&＃xff0c;分别是&＃xff1a;

1. 使用哈希算法生成唯一值

2. 使用分布式唯一 ID 生成作为锻炼 ID

下面我们针对这两个方案进行详细的分析。

哈希算法生成短链

要生成一个短链&＃xff0c;我们可以将原有的长链做一次哈希&＃xff0c;然后就可以得到一个哈希值&＃xff0c;如下面所示。

https://mp.weixin.qq.com/s?__biz&＃61;MzA4MjIyNTY0MQ&＃61;&＃61;&mid&＃61;2647743787&idx&＃61;1&sn&＃61;1caec8eb1b81d6ee5dd7ba7fa05ac0f1&chksm&＃61;87ad0dadb0da84bb7beb5e4373a14e89fba1130c1bd2a51f4baa8021ec0abe496ce94603b6b4&token&＃61;894028224&lang&＃61;zh_CN#rd↓
29541341303115543223957290326355

那么我们遇到的第一个问题&＃xff1a;使用什么哈希算法&＃xff1f;

我们都知道哈希算法是一种摘要算法&＃xff0c;它的作用是&＃xff1a;对任意一组输入数据进行计算&＃xff0c;得到一个固定长度的输出摘要。我们常见的哈希算法有&＃xff1a;MD5、SHA-1、SHA-256、SHA-512 算法等。但我们最好还是使用另一种叫做 MurmurHash 的哈希算法。为什么呢&＃xff1f;

因为 MD5 和 SHA 哈希算法&＃xff0c;它们都是加密的哈希算法&＃xff0c;也就是说我们无法从哈希值反向推导出原文&＃xff0c;从而保证了原文的保密性。

但对于我们这个场景而言&＃xff0c;我们并不关心安全性&＃xff0c;我们关注的是运算速度以及哈希冲突。而 MurmurHash 算法是一个非加密哈希算法&＃xff0c;所以它的速度回更快。

这时候我们会遇到第二个问题&＃xff1a;哈希冲突

学过 HashMap 的同学都知道&＃xff0c;哈希冲突是哈希算法不可避免的问题。而解决哈希冲突的方式有两种&＃xff0c;分别是&＃xff1a;链表法和重哈希法。HashMap 使用了链表法&＃xff0c;但我们这里使用的是重哈希法。

所谓的重哈希法&＃xff0c;指的是当发生哈希冲突的时候&＃xff0c;我们在原有长链后面加上固定的特殊字符&＃xff0c;后续拿出长链时再将其去掉&＃xff0c;如下所示。

原有长链&＃xff1a;https://mp.weixin.qq.com/s1caec8eb1b81d6ee5dd7b↓↓  发生哈希冲突↓↓  
补上特殊字符&＃xff1a;https://mp.weixin.qq.com/s1caec8eb1b81d6ee5dd7b[SPECIAL-CHARACTER]↓↓  再次进行哈希

通过这种办法&＃xff0c;我们就可以解决哈希冲突的问题了。如果再次发生&＃xff0c;那么就再进行哈希&＃xff0c;一直到不冲突位置。一般来说&＃xff0c;哈希冲突的可能性微乎其微。

好了&＃xff0c;现在我们通过哈希算法得到了一个哈希值&＃xff1a;29541341303115543223957290326355&＃xff0c;变成了这样&＃xff1a;http://dwz.com/29541341303115543223957290326355。

原本很长的网址变得比较短了&＃xff0c;但整体看起来还是有点长。

有没有办法让网址变得再短一点呢&＃xff1f;

我们知道在网址 URL 中&＃xff0c;常用的合法字符有 0&＃xff5e;9、a&＃xff5e;z、A&＃xff5e;Z 这样 62 个字符。如果我们用哈希值与 62 取余&＃xff0c;那么余数肯定是在 0-61 之间。

这 62 个数字刚好与 62 个合法网址字符一一对应。接着&＃xff0c;我们再用除 62 得到的值&＃xff0c;再次与 62 取余&＃xff0c;一直到位 0 为止。通过这样的处理&＃xff0c;我们就可以得到一个字符为 62 个字符、长度很短的字符串了。

上面讲有点晦涩难懂&＃xff0c;我们来举个例子。假设我们得到的哈希值为 181338494&＃xff0c;那么上面的处理流程为&＃xff1a;

1. 将 181338494 除以 62&＃xff0c;得到结果为 2924814&＃xff0c;余数为 26&＃xff0c;此时余数 26 对应字符为 q。

2. 将 2924814 除以 62&＃xff0c;得到结果为 47174&＃xff0c;余数为 26&＃xff0c;此时余数 26 对应字符为 q。

3. 将 47174 除以 62&＃xff0c;得到结果为 760&＃xff0c;余数为 54&＃xff0c;此时余数 54 对应字符为 S。

4. 省略剩余步骤

整个处理流程如下图所示&＃xff1a;

可以看到&＃xff0c;我们把 181338494 这个十进制数&＃xff0c;转成了由合法网址字符组成的「62 进制数」—— cgSqq。

到这里&＃xff0c;我们不仅生成了短链&＃xff0c;还将短链的长度极大地缩短了。

这就是使用哈希算法生成唯一锻炼的全部内容了&＃xff0c;我们总结一下&＃xff1a;首先&＃xff0c;使用 MurmurHash 生成哈希值&＃xff0c;并且用重哈希法解决哈希冲突的问题。接着&＃xff0c;将 10 进制的哈希值转成 62 进制的合法网址字符&＃xff0c;从而缩短网址长度。

分布式 ID 生成短链

上面使用哈希算法生成唯一短链的方式&＃xff0c;相对来说是比较形象的。但其实我们也可以用分布式 ID 的方式&＃xff0c;来完成唯一短链的生成。

例如第一次请求的长链&＃xff0c;我们为其生成一个唯一 ID&＃xff0c;将其长链与唯一 ID 对应起来。第二次请求&＃xff0c;我们再为其生成一个唯一 ID&＃xff0c;再次将长链与唯一 ID 对应起来&＃xff0c;如下所示。

第一次请求&＃xff1a;https://mp.weixin.qq.com/s1caec8eb1b81d6ee5dd7b↓↓  
生成短链&＃xff1a;https://dwz.com/1021000001第一次请求&＃xff1a;https://mp.weixin.qq.com/s1caec8eb1b81d6ee5ff7b↓↓  
生成短链&＃xff1a;https://dwz.com/1021000002

因为生成的唯一 ID 也可能非常长&＃xff0c;因此我们可以采用上面同样的方式&＃xff0c;将 10 进制的唯一 ID 转成 62 进制的合法网址字符&＃xff0c;从而缩短字符长度。

那么接下来的问题就变成了&＃xff1a;如何设计一个全局唯一 ID 发号器了。

对于如何设计一个全局唯一的 ID 发号器&＃xff0c;就属于另外一个话题&＃xff0c;我们这里就不深入探讨了。

性能优化

看到这里&＃xff0c;我们基本上有了一个完整的思路&＃xff1a;拿到长链地址后&＃xff0c;可以用哈希算法或唯一 ID 分号器获取唯一字符串&＃xff0c;从而建立长链与短链的映射关系。为了缩短短链长度&＃xff0c;我们还可以将其用 62 进制数表示&＃xff0c;整个短链生成过程如下图所示。

短链生成完&＃xff0c;并且已经存到了数据库中&＃xff0c;接下里该使用了。通常的做法是会根据请求的短链字符串&＃xff0c;从数据库中找到数据&＃xff0c;然后返回 HTTP 重定向原始地址。而在不断使用过程中&＃xff0c;还有一些可能发现的优化点&＃xff0c;这里简单讲讲。

索引优化

如果使用关系型数据库的话&＃xff0c;对于短链字段需要创建唯一索引&＃xff0c;从而加快查询速度。

增加缓存

并发量小的时候&＃xff0c;我们都是直接访问数据库。但当并发量再次升高时&＃xff0c;需要加上缓存抗住热点数据的访问。

读写分离

短链服务肯定是读远大于写的&＃xff0c;因此对于短链服务&＃xff0c;可以做好读写分离。

分库分表

如果是商用的短链服务&＃xff0c;那么数据量上亿是很正常的&＃xff0c;更不用说常年累月积累下的量了。这时候可以一开始就做好分库分表操作&＃xff0c;避免后期再大动干戈。

对于分库分表来说&＃xff0c;最关键的便是根据哪个字段去作为分库分表的依据了。对于短链服务来说&＃xff0c;当然是用转化后的 62 进制数字做分表依据了&＃xff0c;因为它是唯一的嘛。

至于怎么分库分表&＃xff0c;就涉及到分库分表方面的知识&＃xff0c;以及对于系统容量的预估了&＃xff0c;这里就不细说了。有机会的话&＃xff0c;我们找个时间来深入讲讲这方面的内容。

防止恶意攻击

开放到公网的服务&＃xff0c;什么事情都可能发生&＃xff0c;其中一个可能的点就是被恶意攻击&＃xff0c;不断循环调用。

一开始我们可以做一下简单地限流操作&＃xff0c;例如&＃xff1a;

1. 没有授权的用户&＃xff0c;根据 IP 进行判断&＃xff0c;1 分钟最多只能请求 10 次。

2. 没有授权的用户&＃xff0c;所有用户 1 分钟最多只能请求 4000 次&＃xff0c;防止更换 IP 进行攻击。

简单地说&＃xff0c;就是要不断提高攻击的成本&＃xff0c;使得最坏情况下系统依然可以正常提供服务。

总结

本文首先讲了短链存在的三个价值&＃xff1a;简洁、易于使用、节省成本&＃xff0c;接着讲了短链的原理是 HTTP 重定向&＃xff0c;最后着重讲了短链服务的设计思路。

在短链服务的设计思路上&＃xff0c;最重要是解决两个问题&＃xff1a;根据长链生成短链、根据短链找到长链。在根据长链生成短链的思路上&＃xff0c;我们讲了两种实现思路&＃xff0c;分别是&＃xff1a;哈希算法生成短链、分布式全局 ID 生成短链&＃xff0c;其中哈希算法涉及到哈希算法的选择&＃xff0c;以及哈希冲突的处理。

最后我们还列举了一些短链服务后续可能的优化点&＃xff0c;包括&＃xff1a;如何让网址变得更短、索引优化、增加热点数据、读写分离、分库分表、防止恶意攻击等等。

学会的小伙伴点个赞吧~ 感谢阅读&＃xff01;

强势开源一款小程序&＃xff01;
2021-11-07
强力推荐一个完善的物流&＃xff08;WMS&＃xff09;管理项目&＃xff08;附代码&＃xff09;
2021-10-23
推荐一个 Spring Boot &＃43; MyBatis &＃43; Vue 音乐网站
2021-10-19
分享一套家庭理财系统&＃xff08;附源码&＃xff09;
2021-09-20
推荐一个互联网企业级别的开源支付系统
2021-09-04
推荐一套开源通用后台管理系统&＃xff08;附源码&＃xff09;
2021-08-21
一款神仙接私活儿软件&＃xff0c;吊到不行&＃xff01;
2021-07-31
基于 SpringBoot 的仿豆瓣平台【源码分享】
2021-07-18
干掉 Wordpress&＃xff01;这个开源建站神器有点吊&＃xff01;
2021-06-18
从朋友那里搞了 20 个实战项目&＃xff0c;速领&＃xff01;
2021-06-12

如有收获&＃xff0c;点个在看&＃xff0c;诚挚感谢