分布式系统

分布式系统解决单机算力不足、高可用、数据一致性等核心问题。分布式带来的挑战包括网络延迟、节点故障、数据一致性，这些挑战催生了 CAP 定理、BASE 理论、各种共识算法和事务方案。

提示

分布式事务、共识算法等分布式系统核心问题与解决方案

一致性与可用性权衡

分布式事务 从 CAP 定理出发：分布式系统最多只能同时满足一致性、可用性、分区容忍性中的两个。实际工程中分区容忍性是必须选择的，因此需要在 CP 和 AP 之间权衡。金融交易系统选择 CP（强一致性优先），社交网络、秒杀系统选择 AP（高可用优先）。

BASE 理论是对 CAP 中一致性和可用性权衡的结论：基本可用、软状态、最终一致性。与 ACID 的强一致性相比，BASE 提供柔性的最终一致性，适用于高并发场景。

分布式事务方案

分布式事务 文件详细介绍了 2PC、TCC、SAGA、AT 模式。2PC 是同步阻塞的两阶段提交，存在单点故障和数据不一致风险。TCC 是业务层面的两阶段提交，Try 阶段预留资源，Confirm 确认执行，Cancel 取消释放。SAGA 一阶段直接提交本地事务，失败时通过补偿操作回滚。AT 模式（Seata）自动生成回滚 SQL，无侵入但有全局锁。

选型建议：单服务多数据源用 XA 模式，普通业务微服务用 AT 模式，高并发核心系统用 TCC，长事务用 SAGA，异步场景用可靠消息队列。

共识算法

分布式共识算法 解决多个节点如何就同一个值达成一致的问题。FLP 不可能定理指出，在异步网络中只要有一个节点可能崩溃，就不存在算法能一定达成共识。实践中的解决方案：放弃一定，改为概率保证（Paxos/Raft）或最终一致（Gossip）。

Paxos 是 Leslie Lamport 提出的分布式共识算法，是后续多种算法的基础。Raft 的设计目标是比 Paxos 更易于理解，将共识问题拆分为 Leader 选举、日志复制、安全性三个独立模块。Gossip 模拟流行病传播，每个节点随机与其他节点交换信息，最终所有节点获得相同数据。

注册中心与共识

服务治理 中的注册中心是共识算法的典型应用。Nacos 的 CP 模式使用 Raft 保证强一致性，AP 模式使用 Distro（基于 Gossip）保证最终一致性。ZooKeeper 使用 ZAB 协议（基于 Paxos），Eureka 遵循 AP 原则，当心跳失败比例超过 85% 时进入保护模式。

选型建议：分布式配置/元数据用 Raft（etcd），集群成员关系用 Gossip，注册中心 AP 用 Gossip/Distro。