系统设计 101

弄清具体要求
1. 功能需求
  1. 考虑最重要的三个功能
2. 非功能需求
  1. 一些基本的取舍（trade-offs）
核心 entities
1. 系统中的参与者有哪些？满足功能需求需要什么资源？
高层架构
1. 用方框和箭头表示系统的不同组件及其交互方式
2. 组件：基本技术模块，例如服务器、数据库、缓存等
3. 数据如何在系统中流动，以及每次请求（从 API 请求到响应）都会改变哪些状态
API /接口
1. 使用哪种协议（外部 API 用 REST，内部调用用 gRPC）
深挖，一些独立的问题
1. 非功能需求
2. 极端情况和瓶颈

一致性
- 强一致性 (Strong Consistency)：任何时候读到的都是最新写入的数据
- 最终一致性 (Eventual Consistency)：允许短时间内数据不一致，但最终会同步
  - 分布式事务：一个操作跨越多个数据库/服务时，如何处理？
可用性
- 系统能否一直在线，挂了怎么办？
实时性
- 响应有多快，延迟是多少？
扩展性
- 用户从 1 万增长到 1 亿时，系统能不能通过增加机器来扛住压力？
- 垂直扩展 (Vertical Scaling)：给原来的电脑换更强的 CPU、更大的内存（有上限）
- 水平扩展 (Horizontal Scaling)：多几台普通的电脑一起工作（理论上没有上限，这是系统设计的核心）
持久
- 存进去的数据不会丢：多副本
可靠性
- 系统是否不出错
幂等性
- 在分布式环境下，由于重试机制（Retry），同一个请求可能会发送多次。如何保证“支付一次”的请求即便发了三次，用户也只被扣一次钱？
吞吐
- QPS/TPS，并发数

可用性（Availability）和一致性（Consistency）不能同时满足
前提：分区容错性（Partition Tolerance，即网络断开后系统还能继续运行）是必选项

为什么？
假设一个简单系统，只有两台服务器 Node A 和 Node B，它们各自存有一份同样的数据库副本。现在：

现在，系统只有两个选择：

选择一：保证一致性 (CP)
如果想保证一致性 (C)，那么 Node B 不能返回那个旧的 100。

选择二：保证可用性 (AP)
如果想保证可用性 (A)，那么无论如何都要给用户一个响应。

除此之外，比较常见的 trade-offs 还有：

要根据具体的场景来决定讨论哪些 trade-offs。

系统设计就是把技术模块组合起来解决问题，因此需要知道有哪些常用的技术。对每种技术（e.g., 消息队列）应该都至少掌握一种具体的方案（e.g., Kafka）。

架构演进的逻辑：