得益于移动互联网的蓬勃发展，自媒体日益火爆的一起其门槛也越来越低，能够说是全民自媒体。其间内容创造渠道尤为火爆，比方微信大众号、微博、知乎、头条等。随之而来的便是各种「奇葩」需求，比方将长链接转化为短链接。

信任咱们也都见过下面这种短信，极客时间的营销短信，便是短链接，点击之后会跳转到下面这个长链接，那么为啥要那么费事转化成短链接呢，直接用原始链接不就好了么。

https://shop18793264.m.youzan.com/v2/feature/pqzBz4KeGT?dc_ps=2663040806184605700.200001

其实之所以需求短链接其一是由于本钱更低。咱们都知道短信是有字数约束的，所以用长链接的话运营商有或许将短信拆分为两条或许多条来发送，本钱增加一倍。

其二是由于作用更好。好比微博也是有字数约束的，假如如咱们想在微博发一个引流文，引导用户点击咱们的注册链接，但由于微博有 140 字的约束，咱们的注册链接又比较长，假如咱们能够将长链接转化为短链接的话，那岂不是就能够编辑更多的文字来招引用户了么。

别的，有时候是不方便直接放链接的，比方微信大众号是不允许放外链的，那么咱们就能够将链接转化为二维码引导用户扫描二维码即可，短链接比长链接转化出来的二维码更明晰易识别。

那么假如让你来规划一套短链接服务，你会怎么规划呢，一起这也是一道用来调查提名人基本功的常用面试题。

最糟糕的规划

首要咱们整理下需求，即咱们想要让网址变短之后仍然不影响运用。

那么咱们是否能够规划一个算法，将长链接和短链接一一对应呢。该算法接收一个长链接的参数，输出其对应的短链接，当服务器收到短链接的恳求后，再经过逆运算将短链接变成长链接，这样一来不不就很简单完成长链接变短链接的需求了么。

只是这儿有个问题咱们或许疏忽了，事实上世界上的长链接个数是趋于正无量的，有限长度的字符串只能表示有限个短链接，假定短链接的长度为 20 位，那么最多只能表示 62 的 20 次方个短链接，无法做到和正无量个长链接一一对应。

次糟糕的规划

回到原点，咱们只不过是想将长网址变短罢了，变短不便是数据压缩吗，签名算法能够不，比方 MD5、SHA 等散列算法。这些算法能够将任何长度的字符串压缩到固定长度。

但是它们也是有问题的，首要 MD5 有或许磕碰咱们不说，单就 MD5 签名之后的字符串长度是定长这一点咱们是无法接受的，有或许能能咱们的长网址都没有 32 位那么长，这样一来不仅没有变短，反而变长了，这规划不合理。

别的 MD5 这类函数一般用于加密，其功能不是很高，咱们并不关怀安全性，只关怀转化功率和哈希之后的抵触概率罢了。

惯例的规划

既然要把长链接映射成短链接，哈希算法便是做这个事情的嘛，只不过上面的规划选的哈希算法不好罢了。功率高的哈希算法许多，推荐 Murmur 哈希，Murmur 哈希是一种非加密散列函数，适用于一般的基于散列的查找。非加密意味着功率更高，该哈希算法会一个 32 位或许 64 位的值，32 位最多表示 42亿+ 个记载，关于惯例事务来讲足够用了。

假定我么对一个网址哈希之后的值是 4003787369，那么生成的短链接便是https://domain/4003787369，其间前面的域名便是咱们的短链接服务器域名。假如你觉得域名仍是长，那么能够将十进制的 4003787369 转化为 62 进制，转化之后的成果为：4mXtZD，即https://domain/4mXtZD，从 10 位直接缩短为 6 位。

既然是哈希函数，肯定会发生哈希抵触，那如何解决哈希抵触呢？

这儿假定咱们将长链接和短链接的对应联系是存储在数据库的，该表有四列，分别是：id、long_url、short_url、create_time， 咱们能够在short_url列建立一个仅有索引，当咱们得到一个长链接和短链接的对应联系后，直接刺进数据库，假如刺进失利阐明有抵触，这是需求给长链接增加混杂字符串再次求哈希，之后在刺进，假如还抵触就重复刚才的过程，直到刺进成功。

事实上 Murmur 哈希算法的抵触是很低的，基本能够疏忽。

最佳规划

除了对长链接进行哈希运算之后，咱们还能够经过发号策略，给每一个长链接发一个号码，你能够把发号策略理解为 ID 生成器。

这样子，第一个来的长网址对应的短链接是https://domain/1，第二个长链接对应的短链接是https://domain/2，依次递加。拿到号码之后，咱们能够将该号码作为主键存储该长网址记载，一起由于 MySQL 根据主键去获取记载的速度是超级快的，所以这种方式咱们不需求担心查询的功能问题。

这儿咱们仅有需求关怀的便是发号策略了，事务量不大的话，咱们能够直接用 MySQL 的自增序列来完成；假如是大型应用，就需求考虑高并发了。咱们能够多布置一些节点，比方布置 1000 个节点，每个发号器发完一个号之后不在自增 1 ，而是自增 1000。比方关于 1 号发号器，其发送的号码依次是：1、1001、2001、3001...，如关于 2 号发号器，其发送的号码依次是：2、1002、2002、3002...

如此一来，即保证了咱们的发号器永久不会宣布重复的号码，也保证了号码是递加的，主键递加关于数据库来说太重要了。

那假如遇到相同的长链接如何处理呢，直接查表吗？

直接查表怕是会糟蹋太多时间，咱们能够做一个 LRU 缓存，当有恳求过来时，咱们只需求判别该网址是否在 LRU 缓存中即可，若存在，则直接回来，否则直接生成对应联系后将该记载加入缓存。

只不过这样一来的话，关于那些不抢手的网址，或许会生成多个对应联系，事实上咱们也没必要非得做到一一对应，一个长链接对应多个短链接对事务来说没什么影响，而且不抢手网址出现频率原本就很低，不会糟蹋多少空间。

短链接原理

打开极客时间发我给的短链接，调出开发者东西来看看网络恳求。

由上图咱们能够得知，阅读器恳求短链接的时候服务器回来了 302 状况码，然后阅读器重新发起了一次恳求到长链接，主要原理便是用到了重定向，咱们知道 302 状况码和 301 状况码都是表示重定向，那么为啥回来 302 而不是 301 呢。

301 是永久重定向，阅读器第一次拿到长链接后，后边再去恳求短链接都不会在恳求短链接服务器了，而是直接从本地缓存获取，正常来说短链接一经生成是不会在改变的了，那么运用 301 状况码不论在正常逻辑方面仍是 http 语义方面都是合情合理的呀，一起对短链接服务器的压力也会小许多。但是假如运用 301 状况码咱们是无法统计到该链接的点击次数的，假如咱们想分析活动的作用的话，点击次数可是一个很重要的目标哦，回来 302 增加点服务器压力是值得的。

总结

关于以上如何生成短链接，咱们介绍了四种方案，其间第一种压根不可行，第二种规划不是很合理，第三种关于事务量不大的系统来说足够了，第四种则是最佳实践。

今天咱们具体论述了如何规划一个高功能短链接服务，该问题看似简单，实则涉及许多知识点，像短链接跳转原理，301 仍是 302，以及如何更快更好的生成短链接，希望小伙伴们能有所收成，下次在遇到这道题时能够吊打面试官。