一、概述

单一部署系统事务处理方式比较简单，因为在同一服务器上，都在一个业务操作里面。然后多个业务操作分别部署到不同的服务器上，那么需要让这些操作要么全部成功，要么全部失败，该如何处理呢？

二、分布式事务产生的原因

从上面本地事务来看，我们可以分为两块：

Service 产生多个节点

Resource 产生多个节点

Service 多个节点

随着互联网快速发展，微服务，SOA 等服务架构模式正在被大规模的使用。

举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。

在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。

这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

Resource多个节点

同样的，互联网发展得太快了，我们的 MySQL 一般来说装***的数据就得进行分库分表。

对于一个支付宝的转账业务来说，你给朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。

多个服务部署到不同的服务器上，分别使用不同的数据库，比如积分，优惠券有两个服务，分别对应不同的数据库。

三、分布式事务解决方案

3.1、可靠消息最终一致性方案

事务：简单说某一个任务会操作多个数据库，要么全部执行成功，要么全部执行失败。事务具备ACID的特性，即原子性、一致性、隔离性和持久性。