无法列入分布式事务处理_浅谈分布式事务的几种解决方案（两阶段提交）

一起吃瓜

什么是分布式事务

对于我们耳熟能详的事务来讲应该是数据库操作的事务，针对简单业务或者架构的数据库事务操作我们不需要考虑分库分表、多服务节点请求的时候要满足单数据库服务的事务ACID特性是比较简单的一件事儿，而一旦业务变的复杂架构变的多样变的开始“分布”的时候，对应事务的保证就需要将“分布”的事务变的跟单机处理一样，所以，所谓分布式事务简而言之就是将分散的事务操作集中起来使得事务操作的数据看起来跟单机事务操作一样。

分布式事务产生的原因

上边已经提到了一部分原因，总结一下：

1、数据库分库分表：单表数据存储较大引起查询更新缓慢等操作的时候会对数据库表拆分，由此有一些事务操作会落在不同的表上，而这些操作可能会有一个表操作成功另一个不成功，这时候就需要分布式事务保证都成功或者都失败。

分库分表

2、系统架构分布式：单体应用系统拆分为各子系统模块，各子系统模块单独操作独立数据库数据，例如在京东商城下单，一个下单操作涉及到订单中心、库存中心、支付中心等模块操作，这些模块的操作完结都要保证数据的一致。

系统分布

解决方案

1、基于XA协议的两阶段提交方案

什么是XA协议？

XA协议是一种分布式事务处理的规范，这个规范规定了事务管理器与资源管理器之间的通信标准。

数据库和交易系统之间通过XA协议实现分布式事务，一般是通过两阶段提交来完成一个全局的事务。

两阶段提交

两阶段提交的参与者：

1 事务的协调者，一般系统中只有一个，协调事务的全局处理。

2 事务的参与者，一般系统中有多个，对事务进行请求、提交、撤销等操作。

第一阶段：请求阶段

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。

在表决过程中，参与者将告知协调者自己的决策：同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。

第一阶段

第二阶段：提交阶段

在该阶段，当所有参与者都准备好了之后，事务协调者通知所有参与者正式提交事务，否则协调者将通知所有的参与者取消事务。

第二阶段

两阶段提交的缺陷

1、XA无法满足高并发场景，因为当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2、协调者存在单点。

3、mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。

4、在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求而其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

三阶段提交

针对两阶段提交存在的缺陷，提出了三阶段提交协议方案，主要是针对协调者和参与者都加入了超时机制，使得参与者与协调者同时都具有判断是否有因为网络异常等问题引起的状态不一致导致处理结果不一致。

同时在第一阶段和第二阶段之间加入了准备阶段，主要为询问参与者是否可以准备提交事务，参与者回应ACK之后，三阶段真正提交事务。

不论是两阶段提交还是三阶段提交也都存在这一些缺陷，而针对高并发场景下，类似MySQL对XA协议支持的局限并不十分适用这种场景，本人在京东业务中还没遇到过(或者是自己的一孔之见)，一般用的比较多的是基于消息的最终一致方案，待后续再谈。