如何设计一个短网址系统

网址短链接就是一些长链接的别名，比如 bit.ly, goo.gl, qlink.me，输入这些链接会跳转到对应的长链接。

1.为什么需要短链接

短链接主要用来为长链接生成更短的别名，用户点击短链接会重定向到原来的长链接，在显示、打印、发送消息、发送推文等场景下，短链接节省了很大的显示空间，更重要的是，用户不太可能去拒绝输入一个短链接。

举个例子，为长链接 https://www.educative.io/collection/page/5668639101419520/5649050225344512/5668600 916475904/ 生成的短链接就是 http://tinyurl.com/jlg8zpc]，短链接的长度仅仅是原来的三分之一。

短链接主要用于优化，可以跟踪单个链接以进行分析受众群体和广告效果，并隐藏关联的原始网址。如果你从未使用过 tinyurl.com，请在上面尝试创建一个短网址，并了解一下他们的服务，这将有助于你理解需求。

2.系统的需求和目标

应在面试开始时就明确需求。面试时请务必提出问题，以找到所设计系统的确切范围。我们的 URL 短链接系统应满足以下需求：

功能需求：

1、 给定一个 URL，我们的服务应为其生成一个较短且唯一的别名，这也是最基本最核心的功能。

2、当用户访问短链接时，我们的服务应将其重定向到原始链接。

3、用户应该可以选择为其 URL 选择自定义格式的短链接。

4、链接将在默认时间间隔后过期，用户可以指定指定到期时间。

非功能需求：

1、该系统应具有很高的可用性。这是必需的，因为如果的服务中断，则所有 URL 重定向将失败。

2、URL 重定向应以最小的延迟实时进行。

3、生成的短链接是不可猜测的，也就是说长链接到短链接的转换是无规律的。

扩展需求

1、数据分析需求：例如，重定向发生了多少次？

2、其他服务可以通过 REST API 访问我们的服务。

3、短链接可以回收。

3.资源估算和约束

很明显，我们的系统将是读任务比写任务繁重，也就是说重定向的请求次数要远多于生成短网址的请求次数。假设读写之间的比例为 100：1，接下来进行一些估算：

流量估算

假设我们每月将有 500 M 新的 URL 生成，其中读写比为 100：1， 可以预测每月有 500 亿次重定向：

100 * 500M => 50B

预测下系统每秒的请求次数 QPS（Queries Per Second）：

500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s

也就是说每秒的写请求次数是 200 次。考虑到读写比就 100:1，那么重定向的 QPS 是：

100 * 200 URLs/s = 20K/s

也就是每秒 2 万次重定向请求。

存储估算

假设我们存储每个短链接的请求（以及相关的短 链接）为 5 年。由于我们预计每月会有 5 亿个新 URL，因此对象总数我们预计将存储 300 亿：

500 million * 5 years * 12 months = 30 billion

假设每个存储的对象大约为 500 个字节，当然，这仅是估算值，我们将需要 15 TB 的总存储空间：

30 billion * 500 bytes = 15 TB

带宽估计

对于写请求，由于我们期望每秒总共 200 个新 URL，我们服务的传入数据将为每秒 100 KB：

200 * 500字节= 100 KB / s

对于读请求，由于我们期望每秒进行约 20 K 的 URL 重定向&