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

时间:2022-05-12 14:31:27

英文原文链接: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)
    下图是估算这个值的方法,可以参考一下:
  • System Design——系统设计过程(一)约束和用例
  • 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    未完待续...