System Design——系统设计过程(三)理解瓶颈

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

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

系统设计过程：

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

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

往往你会发现，由于各种问题的限制，你的高层次架构设计会存在一个或多个瓶颈。这是完全正常的情况，也是完全可以接受的。没人要求你能够设计一个从头开始能够处理所有问题的系统。它唯一需要的是具有良好的可扩展性，使得你可以在必要的时候通过一些工具和技术提升优化这个系统。

现在你已经有了你的高层次系统设计，就要开始思考当下系统中的瓶颈。也许你的系统需要一个负载均衡器或者多台机器来处理用户的请求。或者由于你的数据量过于庞大，你需要利用多台机器组织一个分布式数据库。为什么会出现这些需要考虑的问题呢？是数据库读写速度过慢？还是说它需要更多的内存缓存？

需要记住的是，通常每一种解决方案都是一种权衡，改变某一方面将会使得在另一些方面性能恶化。然后，重要的是你要能够洞察这些权衡关系，确保你的设计是最优的解决方案，同时能够覆盖题目定义的各种约束和用例。

再次以URL缩短服务为例：

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

这个是先前分析的约束，对于这样的服务来说，关心的就是服务拥塞情况和数据量存储情况。前面已经计算过了，qps是400+，数据量是5年内3TB，hash总大小为36GB。同时每秒写入读出为例，可以总结出，对于每秒qps400+而言并不是什么很难处理的问题，而对于数据的引流和存储这块需要思考如何去优化处理。总结得出，对于这个服务，我们的系统设计瓶颈可能主要存在于数据量处理上。