[!info] related notes

• 所属 MOC：Distributed Systems MOC、Backend Engineering MOC
• 核心分支：数据复制、一致性模型、数据分片
• 协调：Leader Election、分布式锁、分布式事务

分布式系统

[!abstract] 一句话定义 分布式系统由多个通过网络协作的独立节点组成。每个节点只有局部视角，网络延迟没有可靠上界，节点可能部分失败，因此系统必须在不确定性下处理复制、一致性、协调、扩展与恢复。

为什么一旦跨节点，问题就变了

单进程内通常可以直接观察函数返回、共享内存和锁状态；跨节点后：

no response
→ request lost?
→ response lost?
→ server slow?
→ server crashed?
→ network partition?
→ operation already committed?

调用方无法仅凭 Timeout 判断远端是否执行成功。这是幂等、Retry、Reconciliation 和共识存在的根因之一。

最重要的心智模型：Partial Failure

Node A healthy
Node B healthy but unreachable from A
Node C crashed
Client can reach A but not B

系统不是简单的“全好”或“全坏”。不同参与者可能同时持有不同、但各自合理的观察。

[!warning] 网络分区不是断网这么简单 只要一组节点之间无法在业务要求的时间内可靠通信，就必须按 Partition 风险处理；延迟过高在工程上也可能等价于不可达。

四类核心问题

1. Communication

消息会延迟、重复、丢失、乱序；连接断开不等于操作未执行。

对应：Timeout、Retry、Idempotency、Delivery Semantics。

2. State

同一逻辑数据存在多个副本，不同节点更新与可见时间不同。

对应：Replication、Consistency Model、Conflict Resolution。

3. Coordination

多个节点需要决定谁能推进共享状态、谁拥有任务或资源。

对应：Quorum、Leader Election、Lease、Fencing、Consensus。

4. Scale

单节点容量、吞吐或故障域不足，需要 Sharding、Load Balancing 和并行处理。

扩展会进一步增加跨分片查询、再平衡和事务成本。

没有完美全局时钟

节点时钟可能偏移，网络延迟也不稳定。因此：

• Wall Clock 适合展示时间，不一定足以决定因果顺序；
• Timestamp 相同或更大，不自动证明事件更晚发生；
• TTL / Lease 需要考虑时钟和 Pause；
• 顺序常由 Log Position、Term / Epoch、Revision 或 Logical Clock 表达。

并发与分布式的区别

并发	分布式
多个执行单元可能共享进程/内存	节点通过网络通信，没有共享内存假设
锁和内存可见性是主要问题	Partial Failure、消息不确定和多副本是额外问题
进程崩溃常影响整个地址空间	节点可独立故障，其他节点继续运行

分布式系统一定涉及并发，但并发程序不一定分布式。

微服务不等于分布式理论本身

微服务是一种部署和组织架构；分布式系统是它必须面对的底层问题集合。数据库复制、Kafka、etcd、CDN 即使不是“业务微服务”，同样是分布式系统。

一条设计主线

先定义业务不变量与故障容忍
→ 决定是否需要 Replication / Sharding
→ 选择 Consistency Model
→ 明确 Leader / Quorum / Ownership
→ 设计 Timeout / Retry / Idempotency
→ 设计 Recovery / Reconciliation
→ 建立 Observability and Operations

不要从“选 Kafka、Redis 还是 Kubernetes”开始设计。

最小故障推演

假设 Client 请求创建订单：

Client → Service A → DB commit succeeds
                       ↓
                 response lost
Client times out and retries to Service B

系统必须回答：

• 两个实例如何识别同一逻辑请求？
• 第二次请求会不会再创建订单？
• 结果从哪里查询？
• Trace 怎样把两次 Attempt 关联？

这就是分布式正确性落到业务层的方式。

掌握标准

• 能解释 Partial Failure 和 Unknown Outcome。
• 能说明为什么跨节点没有可靠共享内存和全局时钟。
• 能区分 Replication、Sharding、Coordination 与 Transaction。
• 能推演 Timeout + Retry 如何产生重复副作用。
• 能先定义不变量和故障模型，再谈具体中间件。

Related notes

• CAP 定理
• 数据复制
• 一致性模型