常见的7种分布式解决方案(2pc,3pc,Tcc,Seta、本地事务....)

一 分布式事务

1.1 分布式事务

在分布式系统中一次操作需要由多个服务协同完成，这种由不同的服务之间通过网络协同完成的事务称为分布式事务。

1.首先满足事务特性：ACID

2.而在分布式环境下，会涉及到多个数据库

总结：分布式事务处理的关键是：

1需要记录事务在任何节点所做的所有动作，事务进行所有的操作要么全部提交，要么全部回滚。目的是：保证分布式系统中的数据一致性。

二 方案1:2pc

2.1 分布式事务2PC流程

 2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由TC事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。

4.2 第一阶段：准备阶段

由事务协调者询问通知各个事务参与者，是否准备好了执行事务：

1.协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复

2.各参与者执行本地事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）

3.如参与者执行成功，给协调者反馈同意，否则反馈中止，表示事务不可以执行。

流程如下：

 4.3 第二阶段：提交阶段

协调者收到各个参与者的准备消息后，根据反馈情况通知各个参与者commit提交或者rollback回滚

4.3.1 如果正常提交阶段

当第一阶段所有参与者都反馈同意时，协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，具体流程如下：

1. 协调者节点向所有参与者节点发出正式提交的 commit 请求。
2. 收到协调者的 commit 请求后，参与者正式执行事务提交操作，并释放在整个事务期间内占用的资源。
3. 参与者完成事务提交后，向协调者节点发送ACK消息。
4. 协调者节点收到所有参与者节点反馈的ACK消息后，完成事务。

正常提交时，事务的完整流程如下：

 4.3.2 如果异常回滚阶段

如果任意一个参与者节点在第一阶段返回的消息为中止，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时，那么这个事务将会被回滚，具体流程如下：

1.协调者向所有参与者发出 rollback 回滚操作的请求

2.参与者利用阶段一写入的undo信息执行回滚，并释放在整个事务期间内占用的资源

3. 参与者在完成事务回滚之后，向协调者发送回滚完成的ACK消息

4.协调者收到所有参与者反馈的ACK消息后，取消事务

事务回滚，流程如下：

4.4 分布式2pc的优点与缺点

优点: 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

缺点: 二阶段提交确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的

1.性能问题：执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景

2.可靠性问题：2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）。

3.数据不一致：两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。