概述
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，以上是百度百科的解释。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证数据库中的数据一致性以及原子性。
分布式事务产生的场景
查询了下，发现网上有很多人已经总结了，这里我先搬过来，然后在分析下，因为我觉得说的不清晰。
跨JVM进程产生分布式事务
典型的场景就是微服务架构：微服务之间通过远程调用完成各自的事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。
跨数据库实例产生分布式事务
单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。
多服务访问同一个数据库实例
订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，不过这情况比较少，只有在跨服务访问的时候才会出现。
分布式服务调用链路
第一种，事务嵌套
第二种，事务分离
这两种是事务调用的最常见也是最典型的场景，但是都有一个问题，也是导致在多服务访问同一个数据库实例中出现分布式事务的场景：当远程调用让Service B成功了，由于网络问题远程调用并没有返回，此时本地事务提交失败就回滚了Service A的操作，此时Service A与Service B的数据就不一致了。
所以，不管是多数据库还是多应用服务的场景下的应用分布式部署，对于某一个业务下(比如订单扣减)，一旦有异常，都需要回滚，一旦事务都成功了，都需要成功；而这中间有一个最大的影响因素，就是远程调用。由于远程调用的阻碍性，Serivce A与Service B并不能感知到彼此的事务是否执行成功，也就不能正确的回滚或是提交。而对于分布式解决方案的应用，其解决的就是这层远程调用的态势感知；即，根据各服务事务(分支事务)的执行情况来具体判断是否事务可以提交，而不是被远程调用所影响。
Seata的AT模式就是中间加了一层协调器TC，管理分支事务的执行状态；而Sagas模式则是通过事务的执行状态在事务间的传递来控制分支事务的提交与回滚。
参考：《分布式事务》
