分布式系统

CAP 定理：三选二的无奈

2000 年 Eric Brewer 提出 CAP 定理：分布式系统无法同时满足一致性（所有节点读到相同数据）、可用性（请求总能得到响应）、分区容忍性（网络分区时系统仍能运行）三者。由于网络分区是分布式系统的常态，实践中只能选 CP 或 AP。

ZooKeeper、etcd 是 CP 系统（一致性优先，网络故障时可能拒绝写入）；DynamoDB、Cassandra 是 AP 系统（可用性优先，允许短暂数据不一致，用「最终一致性」收敛）。选型要看业务：银行账户余额必须 CP，社交网络点赞数选 AP 完全可以接受。[1]

共识算法与故障恢复

多节点如何就「谁是主节点」达成一致？这是分布式共识问题。Paxos 算法（Lamport，1989）是理论基础，但实现极为复杂。Raft（2013，Ongaro & Ousterhout）是专为工程可读性设计的替代品，etcd、TiKV、CockroachDB 均采用 Raft。

• Leader 选举：节点互发心跳，超时未收到心跳则发起投票，多数票胜出
• 日志复制：Leader 收到写请求，先写本地日志，再并发同步到 Follower，多数节点确认后才提交
• 脑裂防护：网络分区时少数派节点无法获得多数投票，拒绝写入，避免双主