System Design——系统设计过程(一)约束和用例

英文原文链接：https://www.hiredintech.com/classrooms/system-design/lesson/55

从这一节开始，开始介绍当拿到一个System Design问题时候应该如何处理。

-----------------------------分隔符------------------------------------------------------------------------------------

系统设计过程：

Step 1  约束和用例
Step 2  抽象设计
Step 3  理解瓶颈
Step 4  可扩展性设计
-----------------------------分隔符------------------------------------------------------------------------------------

Step 1  约束和用例

和算法设计相同，系统设计问题同样也没有得到全面而明确的定义。考虑一下上一篇文章中提到的URL缩短服务（设计一个类似“bit.ly”的URL缩短服务），对于这个问题其实有许多不明确的地方。再没有了解清楚的情况下，设计出一个恰当的解决方案是几乎不可能的事情。

在拿到一个问题的时候，第一件事情是要明确系统的约束和系统需要满足哪些用例。通常，在面试中，每部分面试官想考察的是你能否立刻获取这个问题的需求，同时设计一个能够覆盖满足这些需求的解决方案。永远不要期待能够在一个问题没有清楚地被表述的时候能够解决它！

举个例子来说，URL缩短服务可能受众只有几千的用户，但每个用户可能会共享数百万个URL。它可能需要处理短URL上数以百万的点击，也有可能点击量只有几十。这个服务可能需要对每个短URL提供扩展性的统计（这会增加数据存储量），当然也有可能没必要提供这个功能。

下面以URL缩短服务为例子，分析约束和用例：

用例（系统需要完成的功能）：

缩短URL：将一个长URL转换为一个短URL
重定向：接收到一个短URL后，重定向到长URL，即定向到真实地址
自定义URL功能
统计分析功能
链接自动过期（为短URL设置expiration time）
手动删除链接
UI或者API（这个service是一个有界面UI可供直接操作的web service或者website还是提供API供其他服务调用）

在实际场景下，可能并不是上面都需要实现。在我们后文的讨论中，暂时不考虑后面斜体的功能部分。

约束（性能指标）：（do some math！）

每月新增URL：100million
每月request数：1billion（每个URL的生命周期为1-2周，在此假设为平均值~10天。假设点击数为1次/天，所以100million × 10days × 1 click/day = 1billion/month）

下图是估算这个值的方法，可以参考一下：



10%的流量流向缩短URL服务，90%流量流向重定向
每秒request数：400+（40：缩短；360：重定向）
5年内6billion urls
每个URL大小为500字节
每个URL的hash值为6字节
五年时间，url总大小为3TB，hash总大小为36GB
每秒写入的新数据约为20KB

上面的数据实际上都是估算的，为了能够得到尽可能准确的估算，实际上是需要更多的以往数据和经验来做支持的！所以，必要的数据准备是肯定的。

Step 2、Step 3、Step 4    未完待续...