短链接服务—业务设计&实践（微信小程序码scene长度限制）

catkin_ws

已于 2024-08-30 16:43:43 修改

阅读量309

点赞数 2

文章标签：短链接系统设计 system design 小程序码 scene 长度限制 getUnlimited

于 2024-08-29 15:04:31 首次发布

本文链接：https://blog.csdn.net/catkin_ws/article/details/141673694

版权

1 什么是短链接服务

短链接也称短网址、短链。由于短信、微博等平台，对于内容有长度限制，过长的 url 不适合直接在微信、短信等平台直接发送原始地址，需要缩短长度。转换后的短网址用于消息发送，也可以避免过多的无用信息影响用户体验。
示意图如下

在这里插入图片描述

2 短链服务需求分析

2.1 用户核心诉求是什么

在这里插入图片描述

1 用户使用短链服务为每个长 URL 生成唯一的短 URL，并存储起来。
2 用户访问这个短 URL，请求重定向到原始长 URL。短 URL 可以是服务自动生成的，也可以是用户自定义的（短 URL 没被使用）
3 管理员可以通过 web 后台检索、查看短链系统的使用情况
4 短 URL 有效期（基于具体业务可自定义），后台定时任务会清理超过有效期的 URL，以节省存储资源，同时回收短 URL 地址链接资源。

2.2 业务场景->性能指标估算

访问流量多大？
- 每天生成 1 亿个 URL
缩短的 URL 是多长？短的定义？
- 尽可能的简短
在缩短的 URL 中允许使用哪些字符
- 缩短的 URL 可以是数字（0-9）和字符（a-z、A-Z）的组合
- 可以不使用特殊字符防止urlencode误伤（+在URL中表示空格；/用于分隔不同路径）

粗略估计：

写操作：每天生成 1 亿个 URL。
写操作每秒：1 亿 / 24 / 3600 = 1160
读操作：读写比10：1，QPS：1160 * 10=11600
假设 URL 缩短服务运行 10 年，意味着支持 1 亿 * 365 * 10= 3650 亿记录。
假设平均 URL 长度为 100byte（一条记录）
超过 10 年的存储需求（不过期）：3650 亿 * 100 字节 * 10 年 = 365 TB
读写带宽
- 写： 1160*(100+100)=226KB/s（网络请求大小）
- 读：2.26MB/s (10:1)
缓存所需内存
- 按照28原则，每天请求的20%进行缓存100byte116003600*24=18.6G

2.3 非功能性需求

生成快：tp99时延低，例如低于60ms
重定向快：去除必不可少的网络请求（301or302）；尽量保证服务反查快
不可预测防数据泄漏：不能猜测某个短 URL 是否存在，也不能猜测短 URL 可能对应的长 URL 地址内容

3 概要设计&调研

3.1 缩短链接

经调研业界相关的最佳实践，可以借鉴编解码思想
在这里插入图片描述

3.1.1 单向散列函数生成短 URL

散列函数，也可以理解为哈希函数必须满足以下要求：

每个长 URL 必须散列到一个哈希值。
每个哈希值都可以映射回长 URL

在这里插入图片描述
为了缩短一个长的 URL，应该实现一个哈希函数，它将一个长的 URL 散列到一个字符串中。
简单的解决方案是使用著名的哈希函数，如CRC32、MD5 或 SHA-1。
下表比较了在此 URL 上应用不同的哈希函数后的哈希结果

哈希类型	哈希值
CRC32	5cb54054
MD5	5a62509a84df9ee03fe1230b9df8b84e
SHA-1	0eeae7916c06853901d9ccbefbfcaf4de57ed85b

即使是最短的哈希值（来自 CRC32）也有8位字符。有没有办法更短呢？

可以考虑使用哈希值的前 n 个字符；但是，这种方法可能会导致哈希冲突。不过可以递归地附加一个新的预定义字符串，直到没有发现更多的冲突为止。如图所示
在这里插入图片描述生成之前先查询一次存储系统看是否存在 shortURL ，这会影响生成的性能。
如果按照这个路子继续优化，可以考虑构建布隆过滤器拦截回源请求，但要处理好漏判问题

3.1.2 自增长短 URL

可以借鉴别的编解码方式，如Base64 编码，常用于将二进制数据转换为文本格式，以便在文本协议中传输，例如电子邮件附件或嵌入 HTML 中的图像。标准Base64编码关系表如下：
在这里插入图片描述
但是在链接中由于传输过程中的编解码（urlencode、urldecode）对于一些字符会特殊处理，其中“+”和“/”在 URL 中会被编码为“%2B”以及“%2F”，而“%”在写入数据库的时候又和 SQL 编码规则冲突；防止这种误伤行为，可以考虑只使用字母和数字组合进行编解码。具体有很多变种方案，如Base62

Base62：

从它的名字来看，Base 62 是一种使用 62 个字符进行编码的方式。
映射分别是： 0-0、…，9-9、10-a、11-b、…，35-z、36-A、…，61-Z，其中“a”代表10，“Z”代表61。
7位即可达到3.5万亿

在这里插入图片描述
举个例子10进制的11157转为62进制=[2,55,59]=2TX

在这里插入图片描述

3.1.3 方案选型对比

散列函数	自增长短URL
固定的短 URL 长度	短 URL 的长度是不确定的。它随 ID 增长
不需要唯一 ID 生成器	依赖于一个唯一 ID 生成器
可能碰撞且必须被处理	不可能碰撞因为 ID 是唯一的
不可能判断出下一个可用短 URL，因为它不取决于 ID	如果 ID 按 1 递增则很容易判断下一个可用短 URL。这可能是一个安全问题

结论：多数业务场景使用自增长短URL方案即可

使用散列函数需解决冲突，如获取前先查询数据是否存在，防止恶意请求需引入布隆过滤器等技术手段
使用自增长短URL，唯一ID生成器较容易实现，redis or mysql均可，符合多数业务场景；安全问题引入check机制即可

3.2 存储系统设计

短链服务设计重点在于缩短链接，存储部分无特殊要求，扩展后满足读写性能要求，OLTP相关组件均可，如选择MySQL

数据实体关系可参考如下：
在这里插入图片描述
此处唯一标识数据的是id（唯一id生成器），反向查询可建立shortURL短链的B+树二级索引，若需要正向查询还需要建立longURL索引；
理论可以，在实践中效果并不好，第4部分会介绍工程中的优化

3.3 流程设计

3.3.1 生成短链

在这里插入图片描述
如图所示，执行流程如下：

① longURL 是输入。
② 系统会检查该 longURL 是否在数据库中。
③ 如果是，则意味着 longURL 之前已被转换为 shortURL。在这种情况下，从数据库中获取 shortURL 并将其返回给客户端。
④ 如果不是，则该 longURL 是新的。一个新的唯一 ID（主键）由唯一 ID 生成器生成。
⑤ 将 ID 转换为 shortURL。
⑥ 创建一个具有 ID、shortURL 和 longURL 的新数据库行

3.3.2 短链获取原始链接

在这里插入图片描述
如图所示，执行流程如下：

① 用户单击一个简短的 URL 链接： https://tinyurl.com/zn9edcu
② 负载均衡器将请求转发到 web 服务器。
③ 如果缓存中已经在 shortURL 中，请直接返回 longURL。
④ 如果缓存中不存在 shortURL，从数据库中获取 longURL。如果它不在数据库中，则很可能是一个用户输入了一个无效的 shortURL。
⑤ 该 longURL 将返回给该用户。