网址短链接就是一些长链接的别名,比如 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 重定向