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