分布式CAP定理
CAP 定理
在一个分布式系统中，以下三个特性不可能同时完全满足，最多只能满足其中两个：
C（Consistency，一致性）：
所有节点在同一时间看到的数据是完全一致的（即更新操作成功并返回后，所有节点都能获取到最新值）。A（Availability，可用性）：
只要收到用户的请求，系统就必须在合理时间内返回一个非错误的响应（即系统始终处于可用状态，不会拒绝服务）。P（Partition tolerance，分区容错性）：
当分布式系统中的网络出现分区（如节点间通信中断）时，系统仍能继续运行（即对网络故障的容忍能力）。
为什么三者不可兼得？
在分布式系统中，网络分区（P）是不可避免的（如网络故障、延迟等）。因此，实际设计中往往需要在 C 和 A 之间做权衡：
- 若优先保证 C + P（CP 系统）：网络分区时，为了保证数据一致，可能会拒绝部分节点的请求（牺牲可用性）。
- 若优先保证 A + P（AP 系统）：网络分区时，为了保证所有节点可用，可能会返回不一致的数据（牺牲一致性）。
CP 系统
是指在分布式系统中，通过强一致性协议（如 Raft）、多数派确认和故障检测，优先保证一致性（C）和分区容错性（P），牺牲可用性（A） 的设计。适合对数据一致性要求极高的场景（如金融交易、分布式锁）。
强一致性优先（Consistency First）
所有节点必须达成数据一致后才响应客户端，不允许 “脏读” 或 “中间状态”。例如：分布式锁服务必须保证同一时间只有一个客户端获取锁。
采用强一致性协议确保数据同步，常见选择：Paxos/Raft：通过选举 Leader 节点协调写入，确保多数节点确认后才提交数据。Raft 更易实现，适合工程落地（如 etcd、Consul 采用）。2PC（两阶段提交）：适合中心化架构，但容错性较差（协调者故障会导致阻塞）。
集群成员管理：故障检测：通过心跳（Heartbeat）或定期探活识别失联节点（如 ZooKeeper 的 Follower 与 Leader 保持心跳）。法定人数（Quorum）：要求超过半数节点可用才能进行写操作（如 5 节点集群需 3 节点确认，避免分区时两边都能写入）。
数据存储设计：只读副本：可部署只读节点分担读压力，但写操作必须通过主节点（Leader）。版本控制：通过版本号（如乐观锁）避免旧数据覆盖新数据（如 etcd 的 Revision 机制）。
分区容错性保障
网络分区发生时，系统需能识别故障节点，避免数据分裂（脑裂）。例如：通过心跳检测和超时机制标记故障节点。
可用性妥协
分区期间，可能拒绝部分读写请求（返回错误或超时），直到分区恢复或集群重新达成一致。
注意事项
避免过度牺牲可用性
- 分区时可允许读旧数据（弱一致性读），但写操作必须严格保证一致。
- 例如：etcd 提供 “线性一致性读”（通过 Leader 读取）和 “串行化读”（可能读旧数据）两种模式。
网络分区恢复策略
- 分区恢复后，需通过日志同步（如 Raft 的日志复制）让所有节点数据一致。
- 少数派节点需丢弃本地未提交的修改，以 Leader 数据为准。
性能优化
- 读写分离：Leader 处理写请求，Follower 处理读请求（需保证读一致性）。
- 批量操作：减少网络交互，提升同步效率
CP 系统场景
- 分布式锁（如 Redis RedLock、ZooKeeper 分布式锁）：必须保证同一时间只有一个持有者。
- 元数据管理（如 HDFS NameNode、Kubernetes ETCD）：集群配置需强一致。
- 金融交易：转账操作必须确保双方账户余额同步更新
AP系统
AP 系统（Availability + Partition Tolerance）是分布式系统设计中，优先保证可用性（A）和分区容错性（P），而在网络分区时允许一定程度数据不一致的系统。它更注重服务的持续可用，适合对响应速度和服务连续性要求高的场景。
高可用性（Availability）
无论是否发生网络分区，系统都能在合理时间内响应客户端请求（不返回错误），确保服务不中断。
无中心节点：避免单点依赖，采用去中心化设计（如 P2P 或多主节点模式），每个节点可独立处理请求。
本地优先写入，异步复制：写请求优先在本地节点执行并立即返回，数据通过后台线程异步同步到其他节点（如 Cassandra 的 “最终一致性” 复制策略）。
冲突解决机制：分区恢复后，若不同节点存在数据冲突（如同一 key 被修改多次），需通过预设规则解决（如时间戳、版本号、业务逻辑）。
冗余设计：数据多副本存储，即使部分节点故障，仍能从其他副本读取数据。
读写策略：读本地：优先读取本地节点数据，保证低延迟。NWR 模型：可配置 “写 N 个节点，读 W 个节点”，在一致性和可用性间灵活调整（如 Riak）。
故障检测与自动恢复：通过 Gossip 协议传播节点状态，分区恢复后自动触发数据合并（如 Redis Cluster 的槽位迁移）。
分区容错性（P）
网络分区（节点通信中断）时，各分区仍能独立处理请求，不会因部分节点故障导致整个系统不可用。
最终一致性
牺牲强一致性，但保证 “最终一致性”—— 分区恢复后，通过数据同步机制，最终所有节点的数据会达成一致。
AP系统场景
- 社交网络：用户动态、评论等对实时一致性要求低，但需高可用。
- 内容分发：视频、图片等静态资源，允许短期数据不一致。
- 物联网（IoT）：设备状态上报，优先保证设备能持续写入数据。
- 缓存系统：如 Redis Cluster，优先保证缓存服务可用，短暂不一致可接受。