短链接服务就是将一个长的URL转换成一个短的，相当于给原来的URL一个别名或者链接。比如下面这个长网址就是这么长：

#rd

这样缩短：

无论是展示、传输、打印甚至是博文，都能节省更多空间，也很方便

输入和记忆，这对于推特、微博等内容受限的场合，或者需要在短信中包含URL的场合更明显，短URL的优势更加明显。

当在浏览器中使用生成的短链接执行请求时，会发现经过一个302，最终会跳转到原来的地址。

如果我们想开发一个类似的短链接服务，我们应该如何设计它，我们应该考虑什么？

首先，我们来了解一下需求：

1. 我们的服务将为指定的长 URL 生成一个唯一的短 URL。链接应该足够短，以便于复制、打印等。

2. 当用户输入短链接时，我们的服务需要将其重定向回原来的 URL

3. 用户可以指定短网址过期时间，过了这个时间短网址就会过期。

4.判断用户是否有创建权限等

参考上面百度短网址的界面设计，基本上我们上面整理出来的需求都覆盖了。我们为短 URL 创建 API，输入参数应包含以下内容：

返回值是一个短网址。当然，为了防止服务被滥用，占用过多存储空间，以及过滤权限，限制调用次数等，可以再添加一个accessKey，这样只有申请过的用户才能访问。如果有计费要求，也可以据此进行限制。通过以上对输入参数和使用场景的估计，不难发现，相比生成短链接，这是一个读请求重的系统。大部分请求都会通过这些短网址获取原始内容并跳转。因此短链接设计，从数据库扩展到系统必须很容易。设计看上面的短域名，应该不难发现，在短域名之后，会有一个短代码“VDuK5lQT”，就是短域名的关键。这类似于我们每个人的ID号，通过它我们可以找到原始URL。如何生成此密钥“短代码”？让我们想一些想法。方法一：可以自增然后像关系数据库的主键一样使用吗？显然，这里自增是不可用的，自增不能产生字符串。同时，每个DB自增不能全局唯一福利:base64 short_如何设计一个有用的短链接服务？，容易重复。但是可以使用全局生成的思想。类似于数据库中多个DB常见的主键生成任务，它们通过第三方服务生成密钥，一般称为KGS（Key Generation Service），并使用KGS生成随机数字字符串。

通过KGS服务，随机生成一串特定的数字，我们称之为key，然后将这些key存入数据库以备后用。当收到生成短链接的请求时，可以直接从备份库中提取并使用。这种方式更加方便快捷。这里需要注意KGS的高可用，不要出现单点故障。但是，对于备用数据库中预先存在的密钥，仍然有可能多个服务器在并发请求期间获取相同的密钥。这时候可以添加一个新表来存放已经使用过的key。每次移动已使用的密钥时，都会创建一个新的只读备用表。或者KGS预先生成一些加速请求到内存或者缓存中，保证返回到各个服务器时的同步，解决重复问题。这部分工作也可以解决到每台服务器，KGS提供批量生成功能，每台服务器可以自行控制重复问题。方法二：可以通过对URL进行MD5、Base64等计算生成唯一字符串。但是这些加密算法生成的字符串长度比较长，我们只需要6-8位，如果使用截断，重复的概率也比较大。颠倒顺序或交换某些位的顺序也可以减少重复的机会。假设两个人输入相同的长 URL短链接设计，返回相同的短链接可能不合适。为此，我们可以添加一个自动递增的数字。如果有重复则重新生成。

对比上面两种方式，第一种方式不仅不需要对URL进行编码，而且不用担心生成的keys的重复和冲突，因为这些都是KGS处理的，更使用方便快捷。数据复制和分区为了方便数据库的扩展，我们需要进行分区，这样可以存储更多的数据。有几种分区方式： 基于范围 所有以字母“A”开头的短链都在一个分区中，以字母“B”开头的短链在另一个分区中，依此类推。这种查询和存储比较简单。主要问题是分区可能不平衡。有些分区有更多的数据，有些则有更少的数据。 Hash Based 对每个短链接、key或原始链接进行Hash，然后通过规则确定value对应的数据存放在哪个分区。基于Hash方式，如果遇到数据存储问题，可以使用“一致性Hash”方式迁移数据等。为了加快请求，我们可以增加Cache，将更多常用的URL添加到缓存中, 并缓存每次有未命中时将库中的数据更新到缓存中。另外，还可以在Client请求Server的地方、Server请求数据库的地方、应用程序请求缓存的地方添加LoadBalancer，将流量转移到多个Server，以支持更多的请求。在第一张图中，短网址会有一个短链接有效期控制。我们可以通过后台任务定期清理过期链接，释放存储空间，最终成型设计。

以上就是关于《短链接服务的设计方案一览》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器