云计算
背景
分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都涉及到的东西，尤其是微服务架构，几乎可以说是不可避免的。
酸
指正确执行数据库事务的四个基本要素：
原子性(Atomicity)
一致性(一致性)
隔离(隔离)
耐用性(耐久性)
无檐软平帽
CAP原理，又称CAP定理，是指分布式系统中的一致性、可用性和分区容忍度。CAP原则是指这三个要素最多只能同时做到两点，不可能三者兼顾。
一致性：分布式系统中的所有数据备份是否同时具有相同的值。
可用性：集群中部分节点失效后，整个集群能否响应客户端的读写请求。
分区容忍度：从实际效果上来说，分区相当于通信的时限要求。如果系统不能在时限内达到数据一致性，说明存在分区情况，需要在C和A之间进行选择进行当前操作。
基础理论
基础理论是CAP中一致性和可用性平衡的结果。该理论的核心思想是，我们无法实现强一致性，但每个应用都可以根据自身的业务特点，采用合适的方法实现最终的一致性。
基本可用(基本可用)
软状态(软状态)
最终一致性(最终一致性)
解决办法
01
两阶段提交(2PC)
两阶段提交2PC是分布式事务中最强大的事务类型之一。两阶段提交是指分两个阶段提交。在第一阶段，询问事务数据源是否准备好了，在第二阶段，数据被实际提交给事务数据源。
为了确保交易能够满足ACID，应该引入一个协调者。其他节点称为参与者。协调器负责调度参与者的行为，并最终决定这些参与者是否应该提交事务。处理流程如下：
第一阶段
a)？协调器将事务的内容发送给所有参与者，询问是否可以提交事务，并等待回复。
b)？每个参与者执行一个事务操作，并在事务日志中记录撤消和重做的信息(但不提交事务)。
c)？如果参与者成功执行，向协调者反馈是，否则反馈否.
？第二阶段
如果协调器收到参与者的失败消息或超时，则直接向每个参与者发送回滚消息；否则，发送提交消息。两种情况处理如下：
案例1:当所有参与者反馈“是”时，提交事务。
a)？协调器向所有参与者发送提交事务的正式请求(即提交请求)。
b)？参与者执行提交请求并释放整个事务过程中占用的资源。
c)？每个参与者将ack完成的消息反馈给协调器。
d)？在协调器收到来自所有参与者的ack消息后，他完成事务提交。
场景2:当参与者给出否定的反馈时，事务被回滚。
a)？协调器向所有参与者发送回滚请求(即回滚请求)。
b)？参与者使用阶段1中的撤销信息来执行回滚操作，并释放整个事务期间所占用的资源。
c)？每个参与者将ack完成的消息反馈给协调器。
d)？在协调器收到来自所有参与者的ack消息后，事务完成。
问题
1)?性能问题：事务提交阶段所有参与者都处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
2)?可靠性问题：如果协调器有单点故障或失败，提供者将总是被锁定。
3)?数据一致性：在阶段2中，如果协调者和参与者都挂断，数据可能不一致。
优点：尽可能保证数据的强一致性，适用于对数据强一致性要求高的关键领域。(其实不可能是100%%u4FDD。).
缺点：实现复杂，牺牲了可用性，对性能影响很大。不适合高并发、高性能的场景。
02
三阶段提交(3PC)
三阶段提交是两阶段提交的改进版本。3PC最关键的问题是协调者和参与者同时挂机，于是3PC将2PC的准备阶段再次一分为二，这样就实现了三阶段提交。处理流程如下：
第一阶段
a)？协调器向所有参与者发送包含事务内容的canCommit请求，询问是否可以提交事务，并等待所有参与者的回复。
b)？参与者收到canCommit请求后，如果认为可以进行交易操作，则反馈yes，进入准备状态，否则反馈No.
第二阶段
根据参与者的反应，协调者有以下两种可能性。
场景1:所有参与者反馈“是”，协调者预执行事务。
a)？协调人向所有参与者发送预提交请求，并进入准备阶段。
b)？参与者收到预提交请求后，执行事务操作，并在事务日志中记录撤销和重做的信息(但不提交事务)。
c)？每个参与者向协调器反馈ack响应或无响应，并等待最终指令。
情况二：只要有一个参与者给出了no的反馈，或者协调者在等待超时后无法收到所有提供者的反馈，那么交易就中断了。
a)？协调器向所有参与者发送中止请求。
b)？无论参与者从协调器收到中止请求还是在等待协调器请求时超时，他们都将中断事务。
第三阶段
这个阶段的真实交易提交也可以分为以下两种情况。
场景1:所有参与者反馈ack响应，执行真实的事务提交。
a)？如果协调器正在工作，则向所有参与者发出do Commit请求。
b)？参与者收到do Commit请求后，会正式提交事务，释放整个事务过程中占用的资源。
c)？每个参与者将ack完成的消息反馈给协调器。
d)？在协调器收到来自所有参与者的ack消息后，他完成事务提交。
情况2:只要有一个参与者给出了no的反馈，或者协调组在等待超时后无法收到所有提供者的反馈，事务就回滚。
a)？如果协调器正在工作，向所有参与者发送回滚请求。
b)？参与者使用阶段1中的撤销信息来执行回滚操作，并释放整个事务期间所占用的资源。
c)？每个参与者向协调组反馈确认完成的消息。
d)？在收到来自所有参与者的ack消息后，协调组完成事务回滚。
优点：与两阶段提交相比，三阶段提交减少了阻塞范围，协调者或参与者会在等待超时后中断事务。避免协调者的单点问题。当阶段3中的协调器出现问题时，参与者将继续提交事务。
缺点：数据不一致的问题依然存在。当参与者收到预提交请求后等待DOCommit指令时，如果此时协调者请求中断事务，协调者无法与参与者正常通信，参与者将继续提交事务，导致数据不一致。
03
补偿交易(TCC)
TCC是面向服务的两阶段编程模型，采用补偿机制：
条件：
需要实现确认和补偿逻辑。
需要支持幂等性
处理流程：
try阶段主要是检测业务系统，预留资源。
这一阶段主要完成：
完成所有业务检查(一致性)。
预留必要的业务资源(准隔离)。
尝试执行业务。
b)确认阶段主要是对业务系统进行确认和提交。
当成功执行尝试阶段并开始确认阶段时，默认的确认阶段不会出错。也就是说，只要尝试成功，确认就会成功。
c)取消环节主要用于取消在业务执行错误需要回滚的状态下执行的业务，释放预留的资源。
优势：
性能提升：具体业务降低了控制资源锁的粒度，整个资源不会被锁。
数据的最终一致性：基于确认和取消的等幂性，交易最终被确认或取消，一致性
缺点：TCC的尝试、确认、取消操作功能要根据具体的服务来实现，业务耦合度高，增加了开发成本。
04
本地消息表(消息队列)
其核心思想是将分布式事务拆分成本地事务进行处理。
在该方案中，在消费者中增加一个新的交易消息表，消费者在本地交易中处理业务并记录交易消息，轮询交易消息表中的数据发送交易消息，提供者基于消息中间件消费交易消息表中的交易。
条件：
服务消费者需要创建一个消息表来记录消息状态。
服务消费者和提供者需要支持等幂。
需要补偿逻辑。
每个节点启动一个定时线程，检查未处理或发送失败的消息，再次发送消息，即重试机制和幂等机制。
处理流程：
1.服务消费者一起提交业务数据和消息来启动事务。
2.消息通过MQ发送给服务提供者，服务消费者等待处理结果。
3.服务提供者接收消息，完成业务逻辑，并将处理后的消息通知给消费者。
容错处理如下：
当步骤1中的处理出错时，事务回滚，相当于什么都没发生。
当步骤2和3中的处理出现错误时，消息可以重新发送到MQ进行重试，因为它存储在消费者表中。
如果步骤3中的处理是错误的，是业务失败，服务提供者发送消息通知消费者交易失败，此时就变成了消费者发起回滚交易进行回滚的逻辑。
优点：从应用程序设计开发的角度实现消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对MQ中间件特性的依赖。
缺点：绑定了具体的业务场景，高度耦合，无法共享。消息数据和业务数据在同一个数据库中，占用业务系统资源。当业务系统使用关系数据库时，消息服务性能将受到关系数据库并发性能的限制。
MQ事务消息(最终一致性)
支持事务消息的MQ类似于两阶段提交。
基于MQ的分布式事务方案实际上封装了本地消息表，它是基于MQ的，其他协议与本地消息表基本一致。
条件：
a)？需要补偿逻辑
b)？业务处理逻辑需要幂等。
处理流程：
c)？消费者向MQ发送一半消息。
d)在MQ服务器持久保存消息之后，它用ack向发送者确认消息发送成功。
e)？消费者开始执行交易逻辑。
f)？消费者根据本地事务的执行结果向MQ服务器提交第二次确认或回滚。
g)当MQ服务器接收到提交状态时，它将半消息标记为可交付。
h)？服务提供者接收消息并执行本地业务逻辑。返回处理结果。
优势：
消息数据独立存储，减少了业务系统和消息系统之间的耦合。
吞吐量优于本地消息表方案。
缺点：
发送消息需要两个网络请求(半消息提交/回滚)。
需要实现消息查找接口。
05
Sagas交易模型(最终一致性)
Saga模式是分布式异步事务，最终一致事务，灵活事务。佐贺交易有两种不同的实现方式，其中最流行的两种是：
第一，事件/编排编排：没有中央协调器(没有单点风险)，每个服务生成并监听其他服务的事件，并决定是否采取行动。
这个实现中的第一个服务执行一个事务，然后发布一个事件。事件由一个或多个服务监控，然后这些服务执行本地事务并发布(或不发布)新事件。当最后一个服务执行本地事务并且没有发布任何事件时，意味着分布式事务已经结束，或者它发布的事件没有被任何Saga参与者听到。
处理流程：
订单服务保存新订单，将状态设置为丁鹏待定，并发布一个名为ORDER_CREATED_EVENT的事件。
支付服务监听ORDER_CREATED_EVENT并发布事件BILLED_ORDER_EVENT。
库存
货运服务侦听ORDER_PREPARED_EVENT，然后交付产品。最后，它发布ORDER_DELIVERED_EVENT。
最后，订单服务监听ORDER_DELIVERED_EVENT并设置订单完成的状态。
假设库存服务在交易过程中失败。回滚：
库存服务生成产品缺货事件。
订阅服务和支付服务将监听上述库存服务的该事件：
支付服务将向客户退款。
订单服务将订单状态设置为失败。
优点：事件/编排是实现Saga模式的自然方式；它很简单，容易理解，不需要太多的努力来构建，并且所有的参与者都是松散耦合的，因为他们彼此之间没有直接的耦合。如果你的交易涉及2到4个步骤，可能非常适合。
第二，指挥/协调协调者：中央协调者负责集中的事件决策和业务逻辑排序。
Saga Coordinator orchestrator通过命令/回复与每个服务进行通信，告诉它们该做什么。
订单服务保存未决状态，并请求订单传奇协调员(简称OSO)开始订单事务。
OSO向收款服务发送收款执行命令，收款服务回复付款执行消息。
OSO向库存服务发送订单准备命令，库存服务将用订单准备消息进行回复。
OSO向货运服务发送订单交付命令，货运服务将回复订单交付消息。
OSO订单Saga协调员必须提前了解执行“创建订单”交易所需的流程(通过阅读BPM业务流程XML配置获得)。如果出现任何故障，它还负责通过向每个参与者发送命令来撤销之前的操作，从而协调分布式回滚。当你有一个中央协调器来协调一切时，回滚就容易多了，因为协调器默认执行正向流程，回滚时只需要执行反向流程。
优势：
避免服务之间的循环依赖，因为saga协调器将调用saga参与者，但参与者不会调用协调器。
集中式和分布式交易的安排。
只需要执行命令/回复(其实回复消息也是事件消息)，降低了参与者的复杂度。
当添加新步骤时，事务复杂性保持线性，回滚更容易管理。
如果希望在第一个事务完成之前用第二个事务更改目标对象，可以很容易地在协调器上暂停它，直到第一个事务结束。
缺点：在协调器中集中过多逻辑的风险。
更多关于云服务器，域名注册，虚拟主机的问题，请访问西部数码代理官网：www.chenqinet.cn。