解决方案：如何设计有用的短链接服务？
短链接服务就是将一个长的URL转换成一个短的，相当于给原来的URL加别名或者链接。比如下面这个长网址就是这么长：
#rd
缩短后是这样的：
可以在展示、传输、打印甚至博文中节省更多空间，也很方便
对于输入和记忆来说，短网址的优势在推特、微博等内容受限的场合，或者需要在短信中包含网址的场合下更为明显。
当在浏览器中使用生成的短链接执行请求时，我们会发现经过一个302后，我们最终会跳转到原来的地址。
如果我们想开发类似的短链接服务，我们应该如何设计它，我们应该考虑什么？
首先，让我们了解需求：
1. 我们的服务将指定一个长 URL 并为其生成一个唯一的短 URL。链接应该足够短，以便于复制、打印等。
2. 当用户输入一个短链接时，我们的服务需要将它重定向回原来的 URL
3. 用户可以指定一个短网址过期时间，过了这个时间短网址就会过期。
4. 判断用户是否有创建权限等
参考上面百度短网址的界面设计，基本上我们上面整理出来的需求都覆盖了。我们为短 URL 创建一个 API，输入参数应包含以下内容：
返回值是一个短 URL。
当然，为了防止服务被滥用，占用过多存储空间解决方案:如何设计一个有用的短链接服务？，以及过滤权限，限制调用次数等，可以再添加一个accessKey，这样只有申请过的用户才能访问。如果有计费要求，也可以据此进行限制。
通过以上对输入参数和使用场景的估计，不难发现，相比于生成短链接，这是一个读请求重的系统。大部分请求都会通过这些短网址获取原始内容并跳转。因此，从数据库扩展到系统必须很容易。
设计
看上面的短域名，我们应该不难发现，在短域名之后，会有一个短代码“VDuK5lQT”，这就是短域名的关键。这类似于我们每个人的ID号，通过它我们可以找到原始URL。
如何生成此密钥“短代码”？让我们想一些想法。
方法一：
它可以自动递增然后像关系数据库的主键一样使用吗？显然，这里自增是不可用的，自增不能产生字符串。同时短链接服务，每个DB自增不能全局唯一短链接服务，容易重复。但是可以使用全局生成的思想。
类似于数据库中多个DB常见的主键生成任务，它们通过第三方服务生成密钥，一般称为KGS（Key Generation Service），使用KGS生成随机数字串。
通过 KGS 服务，随机生成一串特定的数字，我们称之为密钥，然后将这些密钥存入数据库以备后用。当收到生成短链接的请求时，可以直接从备份库中提取并使用。这种方式更加方便快捷。
这里需要注意KGS的高可用，不要出现单点故障。
但是，对于备用数据库中预先存在的密钥，仍然有可能多个服务器在并发请求期间获取相同的密钥。这时候可以添加一个新表来存放已经使用过的key。
每次移动已使用的密钥时，都会创建一个新的只读备用表。或者KGS预先生成一些加速请求到内存或者缓存中，保证返回到各个服务器时的同步，解决重复问题。
这部分工作也可以解决到每台服务器，KGS提供批量生成功能，每台服务器可以自行控制重复问题。
方法二：
可以通过对 URL 执行 MD5、Base64 等计算来生成唯一的字符串。但是这些加密算法生成的字符串长度比较长，我们只需要6-8位，如果使用截断，重复的概率也比较大。颠倒顺序或交换某些位的顺序也可以减少重复的机会。
假设两个人输入相同的长 URL，返回相同的短链接可能不合适。为此，我们可以添加一个自动递增的数字。如果有重复则重新生成。
对比上面两种方法，第一种方法不仅不需要对URL进行编码，而且不用担心生成的key的重复和冲突，因为这些都是KGS处理的，更加方便快捷使用。
数据复制和分区
为了方便数据库的扩展，我们需要进行分区，这样可以存储更多的数据。有几种分区方法：
基于范围
所有以字母“A”开头的短链都在一个部分中短链接服务，以字母“B”开头的那些在另一部分中，依此类推。这种查询和存储比较简单，主要问题是分区可能不平衡，
有些分区有更多的数据，有些则更少。
基于哈希
对每一个短链接、key或者原始链接进行hash，然后通过规则判断value对应的数据存放在哪个分区。基于哈希的方法，如果遇到数据存储问题
可以通过“一致性哈希”的方式进行数据迁移等。
其他
为了加快请求速度，我们可以增加Cache，将更多常用的URL添加到缓存中，每次缓存未命中时，将库中的数据更新到缓存中。
另外，还可以在Client请求Server的地方、Server请求数据库的地方、应用程序请求缓存的地方添加LoadBalancer，将流量转移到多个Server，以支持更多的请求。
在第一张图中，短网址会有一个短链接有效期控制。我们可以通过后台任务定期清理过期链接，释放存储空间。
最终生成成型设计。
以上就是关于《解决方案：如何设计有用的短链接服务？》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器
相关文章：
相关推荐：