原文链接：
https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR
编者注：本文以一道经典的系统设计面试题：《如何设计TinyURL》的参考答案和解析为例，帮助读者更深入地了解在系统需求分析和设计中，需要考虑的各个方面的细节。
本文将为大家详细讲解如何设计一个类似于TinyURL的URL缩短服务。URL缩短服务提供一个非常短小的URL以代替原来的可能较长的URL，将长的URL地址缩短。
类似的服务有：http://bit.ly，goo.gl，qlink.me,等等。
九、负载均衡器（LB）
我们可以在系统中的三个位置添加负载均衡器：
1、在客户端和应用服务器之间
2、在应用服务器和数据库服务器之间
3、在应用服务器和缓存服务器之间
开始时，我们可以使用简单的循环（Round Robin）负载均衡器的方法，在后端服务器之间平均分配传入的请求。这种方法非常容易实现，不会带来任何开销。除此之外，还有另外一个好处，服务器宕机时，负载均衡器（LB）会将其从循环中取出，并停止向其发送任何流量。
使用循环负载均衡器（Round Robin LB）的方法，我们忽略了一个问题，那就是没有考虑服务器负载。即使服务器过载或运行缓慢，负载均衡器仍然会继续向该服务器发送新请求。为了解决服务器过载问题，可以采用更智能的负载均衡器解决方案，它能够定期查询后端服务器的负载情况，并根据负载调整流量。
十、清除或数据库清理
短链接条目应该永远存在还是应该被定期清除？如果达到用户指定的过期时间，那对应的过期链接应如何处理？
如果我们选择主动搜索过期链接然后删除它们，这种方法会给我们的数据库带来很大压力。其实，我们可以慢慢地删除它们，并进行延迟清理。我们设计的清理服务将确保只有过期的链接将被删除，虽然一些过期链接可能不会及时清理掉，但也不会被返回给用户。
1、当用户试图访问某个过期链接时，我们可以删除该链接并向用户返回一个错误指令。
2、一个独立的清理服务可以定期运行，从存储和缓存中删除过期链接。此服务应该是非常轻量的，并且只能安排在预期用户流量较低时运行。
3、我们可以为每个链接设置一个默认的过期时间（例如，两年）。
4、过期链接删除后，我们可以将key放回key-DB中以供重用。
5、我们是否应该删除一些长时间（比如六个月）没有访问过的链接？这个问题可能比较棘手。但由于存储越来越便宜，我们可以决定保留该链接。
十一、统计数据
一个缩短URL被使用过多少次？用户位于哪里？等等，关于这一系列的统计数据我们又将如何存储呢？如果这是数据库某行存储的一部分并每次被更新，那么当一个热门的URL收到大量并发请求时，会发生什么？
下面这些统计数据值得去跟踪：访问者的国家、访问日期和时间、点击的网页，浏览器，或者访问页面的平台。
十二、安全与权限
用户可以创建私有URL或允许特定用户访问URL吗？
我们可以使用数据库中的每个URL来存储权限级别（公共／私有）。还可以创建一个单独的表来存储有权查看特定URL的用户ID。如果用户没有权限并试图访问URL，可以返回错误（HTTP 401）。假如我们将数据存储在像Cassandra这样的NoSQL列存储(Wide-Column)数据库中，那么用于存储用户权限的数据库表的key将是Hash值（或KGS生成的key）。而表中的列用于存储具有查看URL权限的用户ID。
（完）
未经同意，本文禁止转载或摘编。