分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
1.事务
事务一般指的是逻辑上的一组操作，或者作为单个逻辑单元执行的一系列操作。同属于一个事务的操作会作为一个整体提交给系统，这些操作要么全部执行成功，要么全部执行失败。
总体来说，事务存在四大特性，分别是原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），如下图所示，因此事务的四大特性又被称为 ACID。
- 原子性：事务的原子性指的是构成事务的所有操作要么全部执行成功，要么全部执行失败，不可能出现部分执行成功，部分执行失败的情况。例如在转账业务中，张三向李四转账 100 元，于是张三的账户余额减少 100 元，李四的账户余额增加 100 元。在开启事务的情况下，这两个操作要么全部执行成功，要么全部执行失败，不可能出现只将张三的账户余额减少 100 元的操作，也不可能出现只将李四的账户余额增加 100 元的操作。
- 一致性：事务的一致性指的是在事务执行之前和执行之后，数据库中已存在的约束不会被打破。比如余额必须大于等于 0 就是一个约束，而张三余额只有 90 元，这个时候如果转账 100 元给李四，那么之后它的余额就变成了 -10，此时就破坏了数据库的约束，所以数据库认为这个事务是不合法的，因此执行失败。
- 隔离性：事务的隔离性指的是并发执行的两个事务之间互不干扰。也就是说，一个事务在执行过程中不能看到其他事务运行过程的中间状态。例如，在张三向李四转账的业务场景中，存在两个并发执行的事务 A 和事务 B，事务 A 执行扣减张三账户余额的操作和增加李四账户余额的操作，事务 B 执行查询张三账户余额的操作。在事务 A 完成之前，事务 B 读取的张三的账户余额仍然为扣减之前的账户余额，不会读取到扣减后的账户余额。
- 持久性：事务的持久性指的是事务提交完成后，此事务对数据的更改操作会被持久化到数据库中，并且不会被回滚。例如，在张三向李四转账的业务场景中，在同一事务中执行扣减张三账户余额和增加李四账户余额的操作，事务提交完成后，这种对数据的修改操作就会被持久化到数据库中，且不会被回滚，因为已经被提交了。
数据库事务在实现首先依赖数据库的引擎，对于MySQL数据库而言，必须使用InnoDB数据库引擎。事务的隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性。执行事务时会将所有的操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将会导致事务回滚。
2.分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
分布式事务产生的原因：
1)分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。
2)微服务架构 随着互联网快速发展，微服务，SOA(Service-Oriented Architecture) 等服务架构模式正在被大规模的使用。举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。
需要注意的是：分布式事务不是脱离了本地事务的全新概念。而是基于本地事物之上，增加了一个协调管理者的角色来协调管控各个应用之间的事务操作。
3.分布式事务实现方案
分布式事务不是脱离了本地事务的全新概念。而是基于本地事物之上，增加了一个协调管理者的角色来协调管控各个应用之间的事务操作。简单来说就是，每个应用还是单独管理自己的本地事务，只是最后会由事务协调者来确定全部应用是否都已完成操作。且由事务协调者来确定事务的提交和回滚。从而达到目的。
在分布式事务设计中，应有下面两个角色：
- 事务协调者：协调管控各个应用的本地事务操作、统一完成事务的提交、回滚操作。
- 资源所有者：很好理解。可以理解为分布式环境中各个应用就是各自的资源所有者。
目前市面上大多分布式事务解决方案都是基于2PC实现的，也就是二阶段提交。
2PC（Two-phase commit protocol) 二阶段提交协议，将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段,二阶段提交是一种强一致性设计，2PC 引入一个事务协调者的角色来协调管理各参与者（也可称之为各本地资源）的提交和回滚。
2PC实现产品： Seata是由阿里中间件团队发起的开源项目 Fescar，后更名为Seata，它是一个是开源的分布式事务框架。传统2PC的问题在Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。