分布式系统

借鉴 awesome-distributed-systems (12k⭐)。

CAP 定理（再强调）

最多同时满足两个：
C 一致性 → 所有节点同一时刻数据相同
A 可用性 → 每个请求都能得到响应
P 分区容错 → 网络断开仍能工作

P 必须满足 → 在 C 和 A 之间选：
CP：银行（一致性优先）
AP：社交媒体（可用性优先）

一致性模型

强一致性：写入后立刻能读到（最严格，最慢）
最终一致性：写入后最终能读到（宽松，快）
因果一致性：有因果关系的操作按顺序看到

现实：大多数系统用最终一致性。

Raft 共识算法

三个角色：
Leader   — 处理所有客户端请求，发送心跳
Follower — 被动响应，接收心跳
Candidate — 竞选 Leader 的中间状态

选举：Follower 收不到心跳 → 变 Candidate → 请求投票 → 多数同意 → 变 Leader
日志复制：Leader 收到写请求 → 追加日志 → 发给 Followers → 多数确认 → 提交

幂等性

幂等 = 同一操作执行多次，结果和执行一次相同。

为什么重要：网络重试 → 可能重复执行。
不幂等：扣款 100 元（重复扣 → 扣了 200）
幂等：  设置余额 = 500（重复设 → 还是 500）

实现：唯一请求ID + 数据库唯一约束 + 状态机。

服务治理

服务发现：注册中心（Consul/etcd/Nacos）
负载均衡：轮询/加权/最少连接/一致性哈希
熔断：  连续失败 N 次 → 暂时停止调用 → 过一会重试
降级：  高峰期关掉非核心功能
限流：  令牌桶/漏桶/滑动窗口

分布式事务

2PC（两阶段提交）：
  准备阶段 → 所有参与者说"可以"
  提交阶段 → 协调者说"提交"或"回滚"
  问题：协调者挂了就卡住

Saga（补偿事务）：
  每个步骤有对应的补偿操作
  失败了就逆序执行补偿
  适合：微服务架构

时钟与顺序

不能依赖物理时钟！（NTP 同步有误差）
用逻辑时钟：Lamport 时钟、向量时钟
分布式 ID：Snowflake（Twitter）