分布式系统了解多少-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_35216414/article/details/138966064

本文深入探讨了分布式系统中的事务处理，包括经典的基础理论如CAP理论，详细解析了分布式事务的多种方案，如XA规范、2PC、3PC、柔性事务（BASE理论、TCC、SAGA事务）以及事务消息型和可靠事件队列。此外，还讨论了Seata等分布式事务解决方案和Raft、Paxos等分布式共识算法，为读者提供了全面的分布式事务理解与选型指导。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

经典基础理论

系统设计理念

中心化设计：分为两种角色，“领导” 和 “干活的”，强依赖于"领导"节点。

问题1：“领导”节点的正常响应问题。可以使用主备方案解决。
问题2：“领导”节点的性能瓶颈，影响请求分发。

去中心化设计：不是不要中心，而是由节点来自由选择中心。集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd（Raft算法）。

脑裂问题：指一个集群由于网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群都各自工作，则可能会产生严重的数据冲突和错误。
方案：规模较小的集群就“自杀”或者拒绝服务

分布式事务

分布式事务（Distributed Transaction）特指多个服务同时访问多个数据源的事务处理机制，请注意它与DTP 模型中“分布式事务”的差异。

XA 规范

XA 规范里描述了一个 DTP(Distributed Transaction Processing) 模型，这是一个实现分布式事务处理系统的概念模型。

XA 规范里描述了该模型包含三类角色：

AP：Application Program，应用程序，定义了事务的边界，以及指定了组成一个事务的行为，可以理解为就是事务发起的某个微服务。
RMs：Resource Managers，资源管理器，有多个，可以理解为就是分布式数据库中的每一个数据库实例。
TM：Transaction Manager，事务管理器，负责协调和管理事务，是一个控制全局事务的协调者。

之所以引入 TM，是因为整个全局事务被分散到多个节点之后，每个节点虽然可以知道自己操作是否成功，但是却无法得知其他节点上操作是否成功，靠分散的节点自身并无法保证全局事务的一致性，因此需要引入一个协调者来管理全局，进而才能保证全局事务的 ACID。

TM 与 RM 之间实现事务的完成和回滚，是使用了 2PC（Two-Phase Commit） 协议——即两阶段提交协议来实现的。

XA 规范里还定义了一系列接口，称为 XA 接口，用于 TM 和 RM 之间通讯的接口，主要包含了以下这些接口：

CAP理论

强一致性（Consistency）：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。
可用性（Availability）：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。
分区容错性（Partition Tolerance）：理解为在存在网络分区的情况下，仍然可以接受请求（满足一致性和可用性)。这里的网络分区是指由于某种原因，网络被分成若干个孤立的区域，而区域之间互不相通。

如果放弃可用性（CP without A），意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制地延长，此时，问题相当于退化到前面“全局事务”中一个系统使用多个数据源的场景之中，我们可以通过 2PC/3PC 等手段，同时获得分区容忍性和一致性。

在现实中，选择放弃可用性的 CP 系统情况一般用于对数据质量要求很高的场合中，除了 DTP 模型的分布式数据库事务外，著名的 HBase 也是属于 CP 系统，以 HBase 集群为例，假如某个 RegionServer 宕机了，这个 RegionServer 持有的所有键值范围都将离线，直到数据恢复过程完成为止，这个过程要消耗的时间是无法预先估计的。

如果放弃一致性（AP without C），意味着我们将假设一旦发生分区，节点之间所提供的数据可能不一致。选择放弃一致性的 AP 系统目前是设计分布式系统的主流选择，因为 P 是分布式网络的天然属性，你再不想要也无法丢弃；而 A 通常是建设分布式的目的，如果可用性随着节点数量增加反而降低的话，很多分布式系统可能就失去了存在的价值，除非银行、证券这些涉及金钱交易的服务，宁可中断也不能出错，否则多数系统是不能容忍节点越多可用性反而越低的。

目前大多数 NoSQL 库和支持分布式的缓存框架都是 AP 系统，以 Redis 集群为例，如果某个 Redis 节点出现网络分区，那仍不妨碍各个节点以自己本地存储的数据对外提供缓存服务，但这时有可能出现请求分配到不同节点时返回给客户端的是不一致的数据。
可横向对比的如注册中心的Zookeeper与Eureka，Zookeeper实现CP，Eureka实现AP

CAP与注册中心选型

现在，注册中心的选型有好多种，包括 Zookeeper、Eureka、Consul、Etcd、CoreDNS、Nacos 等，还可以自研。这么多选择，应该选哪个比较好呢？其实，可以先从 CAP 理论去考虑，本质上，注册中心应该是 CP 模型还是 AP 模型的？

对于服务发现场景来说，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费方来说，能消费才是最重要的，拿到不正确的服务提供方节点信息好过因为无法获取服务节点信息而不去消费。
对于服务发现场景来说，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。但是对于服务消费者来说，如果因为注册中心的异常导致消费不能正常进行，对于系统来说则是灾难性的。
服务注册的角度分析，如果注册中心发生了网络分区，CP 场景下新的节点无法注册，新部署的服务节点就不能提供服务，站在业务角度这是我们不想看到的，因为我们希望将新的服务节点通知到尽量多的服务消费方，不能因为注册中心要保证