英文原文链接：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+而言并不是什么很难处理的问题，而对于数据的引流和存储这块需要思考如何去优化处理。总结得出，对于这个服务，我们的系统设计瓶颈可能主要存在于数据量处理上。