什么是分布式事务，以及有哪些解决方案？

什么是分布式事务?

答：指一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。从本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务产生的原因?

1 数据库分库分表

当数据库单表数据达到千万级别，就要考虑分库分表，那么就会从原来的一个数据库变成多个数据库。例如如果一个操作即操作了01库，又操作了02库，而且又要保证数据的一致性，那么就要用到分布式事务。

2 应用SOA化

所谓的SOA化，就是业务的服务化。例如电商平台下单操作就会产生调用库存服务扣减库存和订单服务更新订单数据，那么就会设计到订单数据库和库存数据库，为了保证数据的一致性，就需要用到分布式事务。

总结：其实上面两种场景，归根到底是要操作多数据库，并且要保证数据的一致性，而产生的分布式事务的。

分布式事务解决方案

1、两阶段提交(2PC)

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、Mysql等数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交回滚。

XA实现分布式事务的原理如下：

总结

二阶段提交看起来确实能够提供原子性的操作，但是它存在几个缺点：

• 同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
• 单点故障：由于(事务管理器)协调者的重要性，一旦协调者发生故障。(本地资源管理器)参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。(如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)
• 数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器无法执行事务提交。于是整个分布式系统便出现了数据不一致的现象。
• 二阶段无法解决的问题：参与者在发出commit消息之后宕机，而唯一接收到这条消息的协调者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交了。

2、三阶段提交(3PC)

3PC其实在2PC的基础上增加了CanCommit阶段，是2PC的变种，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效的解决了协调者单点故障的问题。但是，性能和数据一致性问题没有根本解决。

3PC分为三个阶段：CanCommit、PreCommit、DoCommit

CanCommit阶段

它跟2PC的 准备阶段很像，协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

• 事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应
• 响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则返回No

PreCommit阶段

协调者根据参与者的响应情况来决定是否可以进行事务的PreCommit操作。根据响应情况，有以下两种可能：

• 假如协调者从所有的参与者获得的反馈都是Yes，那么就会执行事务的与执行。
• 发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段。
• 事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
• 响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
• 假如有任何一个参与者向协调者发送了No响应，或者等待超时，或者协调者都没有接到参与者的响应，那么就执行事务的中断。
• 发送中断请求：协调者向所有参与者发送abort请求。
• 中断事务：参与者收到来自协调者的abort请求之后(或超时之后，仍未收到协调者的请求)，执行事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况：

• 执行提交
• 发送提交请求：协调接收到参与者发送的ACK响应，那么将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
• 事务提交：参与者接收到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源。
• 响应反馈：事务提交完之后，向协调者发送ACK响应。
• 完成事务：协调者接收到所有参与者的ACK响应之后，完成事务。
• 中断事务
• 协调者没有接收到参与者发送的ACK响应(可能是接受者发送的不是ACK响应，也可能响应超时)，那么就会执行中断事务。
• 发送中断请求：协调者向所有参与者发送abort请求
• 事务回滚：参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
• 反馈结果：参与者完成事务回滚之后，像协调者发送ACK消息。
• 中断事务：协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

原理图如下：

总结

相对于2PC而言，3PC对于协调者和参与者都设置了超时时间，而2PC只有协调者才拥有超时时间机制。这个优化解决了，参与者在长时间无法与协调者节点通讯的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。但是仍然没有解决数据一致性问题，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

3、补偿事务(TCC)

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!