最近一个多月一直在断断续续阅读本书。书中会涉及到一些系统设计相关的技术内容，但个人认为该书更倾向于是一本关于面试技巧的书籍。关于具体的技术细节，如果想要深入了解，那么还是需要另外找其它材料来做补充（当然作者其实在书中也推荐了很多相关材料）。 由于之前没有中文版，自己在阅读过程中也进行了一些翻译，同时记了一些读书笔记，方便在有需要时快速回忆。（昨天看到作者本人在社交媒体上发布了中文版出版的消息，感兴趣的话也请支持正版）

第一章 从零扩展到百万用户

简单概括系统的演进过程：

  1. 单机（仅有web/client，CDN，以及server）
  2. 数据库服务器与应用服务器分离
  3. 添加负载均衡器（好处是故障转移，易于横向扩展等）
  4. 数据库主从复制，读写分离（提升性能，可靠性及可用性）
  5. 添加缓存
  6. 使用CDN缓存静态资源
  7. 分离会话数据，保持web层无状态（便于扩展）
  8. 引入多数据中心
  9. 使用消息队列实现异步通信
  10. 添加日志监控，指标以及自动化工具
  11. 数据库sharding

总结感想：第一章是在high-level上概括了系统演进的过程。在系统设计面试中也可以按照这个思路，从最简单的设计入手，逐步分析可能产生的问题和瓶颈，以及可以通过怎样的手段来解决。

第二章 估值

第二章主要提到了一些对系统容量或性能进行评估时较为常见的数据，如：

  • 2的次方与数据量单位的对应关系，可方便速算

一些典型场景的latency，从中可以提取出一些结论来帮助设计（如memory比disk快，应尽量减少磁盘寻址，在传输数据前可尽量对其压缩等等）

  • 代表可用性的百分比数据

    • 三个九：平均每天宕机约1.44分钟，每年约8.77小时
    • 四个九：平均每天宕机约8.64秒，每年约52.6分钟

常被问到的估计数据包括：

  • DAU，QPS，峰值QPS
  • 单条数据的大小，每天的数据量，5年的数据量
  • 缓存，服务器数量等等

第三章 面试框架

第三章描述了一个系统设计面试的面试框架。

step.1 理解问题，确定设计范围

不要一上来就开始设计，先与面试官进行沟通。对系统的功能，需求，用户量，预计增长速度和规模等等进行充分的沟通后再开始设计。

step.2 提出一个high-level的设计，并确认与面试官达成一致

先不要急着讨论细节，提出初步的设计方案，并积极与面试官沟通寻求反馈。（API endpoints和DB schema是否要在这个环节进行讨论要根据实际情况来定）

step.3 design deep dive

注意选择和明确具体要deep dive的topic。也要注意时间管理，有些topic并不值得花费太多时间来讨论。

step.4 总结

一些follow up或自由讨论其它问题，包括但不限于：

  • 系统瓶颈，潜在改进点
  • 对故障，错误等讨论
  • 监控指标，错误日志，发布
  • 如何处理下一个scale curve
  • …

对于45mins的面试，建议的时间分配

  • 第一步 3-10 mins
  • 第二步 10-15 mins
  • 第三步 10-25 mins
  • 第四步 3-5 mins