分布式事务:指涉及操作多个数据库的事务。事实上，同一个库中的事务的概念被扩展到多个库中的事务。目的是确保分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法知道事务在任何地方做什么。所有动作，提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。
x/open组织(现在的opengroup)定义了分布式事务处理模型。x/opendtp模型(1994)包括应用程序(ap)、事务管理器(tm)、资源管理器(rm)和通信。信息资源管理器(crm)由四部分组成。通常，公共事务管理器(tm)是事务中间件，公共资源管理器(rm)是数据库，公共通信资源管理器(crm)是消息中间件。xa是x/opendt。p定义的交易中间件与数据库之间的接口规范(即接口函数)，交易中间件用它来通知数据库交易的开始和结束，以及提交和回滚。xa接口函数由数据库厂商提供。二阶提交协议和三阶提交协议都是从这个思想中衍生出来的。出去。可以说，两阶段提交实际上是实现xa分布式事务的关键(确切地说，两阶段提交主要是保证分布式事务的原子性，即所有节点要么做，要么根本不做)。
因此，大多数关系数据库通过两阶段提交2pc算法完成分布式事务也就不足为奇了。
1.两阶段/三阶段提交
2pc/3pc的全称是:two/threephasecommit，中文名是two-phase/threephasesubmission；需要引入一种算法，该算法旨在使基于分布式系统架构的所有节点在事务处理过程中具有acid特性。组件作为协调者统一控制所有节点(称为参与者)的操作结果并最终指示这些节点是否应该分两个阶段真正提交操作结果的算法如下:
第一阶段:提交阶段(投票阶段)
第二阶段:执行交易提交(执行阶段)
这种有很多缺点，在复杂场景下通常不推荐使用，除非是非常简单的场景，非常容易提供回滚，依赖的服务非常少。
2.本地方法表
这种实现的想法其实来自于ebay。其基本设计思想是将远程分布式事务分解成一系列本地事务。如果不考虑性能和优雅的设计，可以借助关系数据库中的表来实现。举一个跨行转账的经典例子来描述一下。
第一步伪代码如下:扣除1w，保证凭证消息通过本地事务插入消息表。
第二步，通知对方银行账户已经加了1w。如何通知对方:可以通过轮询，也可以通过mq。
方法
伪代码如下，以跨行转账为例。
尝试{1。在本地更新数据库。如果更新成功，执行第二部分。2.通过mq}catch{rollback()}发送消息如果第一步失败，消息将不会发送到mq。如果第一步成功，第二步失败，捕获异常回滚数据，并确保。数据一致性；
4.交易mq
有些mq直接支持分布式交易，比如阿里srocketmq；rocketmq处理事务消息的一般过程如下:
1.生产者发送待确认的信息；
保存收到的消息，成功后将状态返回给生产者；
3.如果生产者收到的返回是send_ok状态，则执行本地事务操作；
4.根据本地事务执行的结果，生产者是执行提交还是回滚；；
5.如果生产者未能执行第四步中的操作，服务器将在一段固定时间后对处于待确认状态的消息发起回溯请求；
6.生产者收到回溯请求后，返回commit或rollback根据本地事务的结果，对本地事务进行处理；
7.服务器收到结果后执行相关操作。
摘要
可以看出，第一种是保证绝对的一致性，这种在互联网行业很少使用，主要是性能不好；最后四种情况都保证"最终一致性"，应用广泛；另外，分布式事务其实是一个数据一致性问题，可以关注一下。上限理论和基础理论；可以多关注我的相关文章。
联邦调查局。rpc无序的邮政业
