在数字时代，对于高效、简洁的URL管理系统的需求已变得至关重要。诸如 bit.ly、TinyURL 和 ZipZy.in 等短链接服务，在将冗长的网址转化为可分享的短链接方面，发挥着巨大的作用。
让我们通过下面的活动图来深入理解 URL 短链接系统的工作原理：
URL 短链接服务系统设计的需求
1. 功能性需求
- 给定一个长 URL，服务应为其生成一个简短且唯一的别名。
- 当用户访问短链接时，服务应将其重定向至原始链接。
- 链接应在标准的默认时间跨度后过期。
2. 非功能性需求
- 系统应具有高可用性。这一点至关重要，因为如果服务宕机，所有的 URL 重定向都将失败。
- URL 重定向应实时发生，且延迟极低。
- 短链接应具有不可预测性。
容量估算
让我们假设我们的服务每月新增 3000 万次 URL 缩短请求。假设我们将每一次 URL 缩短请求（及其关联的短链接）存储 5年。在这段时间内，该服务将生成约 18 亿条记录。
> 3000 万 5 年 12 个月 = 18亿 (1.8B)
注意： 让我们假设使用 7 个字符来生成短 URL。这些字符是 62 个字符的组合 [A-Z, a-z, 0-9]，类似于 https://zpzy.in/redirecting?code=abXdef2 这样的形式。
数据容量建模
我们来讨论数据容量模型，以估算系统的存储需求。我们需要了解可能需要向系统插入多少数据。思考一下数据库中将存储哪些不同的列或属性，并计算五年的数据存储量。让我们根据以下假设对不同的属性进行分析。
- 假设长 URL 的平均大小为 2KB，即 2048 个字符。
- 短 URL 大小：17 个字符占用 17 字节
- 创建时间- 7 字节
- 有效期时长（分钟） -7 字节
> 上述计算得出，数据库中每个缩短 URL 条目总共占用 2.031KB。
> 如果我们针对 3000 万活跃用户计算总存储量，
> 总大小 = 30000000 * 2.031 = 60780000 KB = 每月 60.78 GB。一年就是 0.7284 TB，而在 5 年 则是 3.642 TB 的数据。
注意： 我们还需要考虑针对如此规模的数据，系统将发生的读写操作。这将决定我们需要使用哪种类型的数据库（关系型数据库 RDBMS 或 NoSQL）。
低层设计!Low-Level-Design-of-URL-Shortening-Service
创建短链接的 URL 编码技术
要将长 URL 转换为唯一的短 URL，我们可以使用一些哈希技术，如 Base62 或 MD5。我们将讨论这两种方法。
#### 1. Base62 编码
- Base62 编码器允许我们使用字符和数字的组合，包含 A-Z, a-z, 0–9 共计 ( 26 + 26 + 10 = 62) 个字符。
- 因此，对于 7 个字符长的短 URL，我们可以支持约 62^7 ~= 3500 亿个 URL，这与 base10 相比是相当充足的（base10 仅包含数字 0-9，所以你只能得到 1000 万种组合）。
- 我们可以为给定的长 URL 生成一个随机数，将其转换为 base62，并将哈希值作为短 URL 的 ID。
> 如果我们使用 base62，并假设服务每秒生成 1000 个短 URL，那么耗尽这 3500 亿个组合将需要 110 年的时间。
C++
CODEBLOCK_34e906c7
Java
CODEBLOCK_0557b138
Python
CODEBLOCK_ed3bb96f
JavaScript
CODEBLOCK_3fe2c039
#### 2. MD5 编码
MD5 同样给出 base62 格式的输出，但 MD5 哈希生成的输出较长，超过 7 个字符。
- MD5 哈希生成 128 位长的输出，所以我们将从这 128 位中截取…