先看个例子：
客户A和客户B的银行账户金额都是10000元人民币，客户A需要把自己帐户中的5000元人民币转到客户B的账户上。
这个过程看似简单，实际上涉及了一系列的数据库操作，可以简单地视为两步基本操作，即从客户A帐户的金额中扣除5000元人民币，以及将客户B帐户中金额添加5000元人民币。
假设第1步数据库操作成功，而第二步失败的话，将导致整个操作失败，并且客户A帐户金额将被扣除5000元人民币。这样就非常悲催！
事务机制可以避免此类情况，以保证整个操作的完成，如果某步操作出错，之前所作的数据库操作将全部失效。
事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。使用事务机制的好处非常明显，开头的例子就是最好的说明。
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义): 分布式访问一个单独的数据资源，以及从一个单独的应用构件访问分布式资源。 在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。
在下面的情况下这个问题更加复杂:
通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
【分析】
事务是单个的工作单元。如果某个事务成功，则在该事务中进行的所有数据更改均会提交，成为数据库中的永久组成部分。如果事务遇到错误且必须取消或回滚，则所有数据更改均被清除。一个逻辑工作单元必须有ACID属性，只有这样才能成为一个事务。ACID属性有以下4个属性。
1．A：原子性（Atomicity）要么全部做，要么就全部不做。
事务必须是原子工作单元。对于其数据修改，要么全都执行，要么全都不执行。
2．C：一致性（Consistency）事务执行后，必须由一个一致状态变为另外一个一致状态。
事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构都必须是正确的。
3．I：隔离性（Isolation）事务之间不能相互干扰。
由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务识别数据时数据所处的状态，或者是另一个并发事务修改它之前的状态，或者是第二个事务修改它之后的状态，事务不会识别中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。
4．D：持久性（Durability）一旦事务完成，对于数据的变更是永久的。
事务完成之后，它对于系统的影响是永久性的。该修改即使出现系统故障也将一直保持。
事务有以下3种运行模式。
q 自动提交事务：每条单独的语句都是一个事务。
q 显式事务：每个事务均以BEGIN TRANSACTION语句显式开始，以COMMIT或ROLLBACK语句显式结束。
q 隐性事务：在上个事务完成时新事务隐式启动，但每个事务仍以COMMIT或ROLLBACK语句显式完成。
说明：还有一种批处理级事务模式，该模式仅应用于多活动结果集（MARS），在MARS会话中启动的Transact-SQL显式或隐式事务变为批处理级事务。当批处理完成时没有提交或回滚的批处理级事务自动由SQL Server进行回滚。
-----------------------------扩展--------------------------
一个大的操作由两个或者更多的小的操作共同完成。而这些小的操作又分布在不同的网络主机上。这些操作，要么全部成功执行，要么全部不执行。分布式事务就是为了保证不同数据库的数据一致性。
拿转帐来说。
张三和李四在不同的城市，存储他们账户信息的服务器也在不同的网络主机上。张三有30元钱，李四有30元钱。张三给李四转账5元就是一个事务。完成这个事务，需要两个操作。首先得从张三账户上扣5元，然后再给李四账户上加5元。事务执行完毕后，必须是两个操作都执行成功，要么都失败。
应用SOA化，也就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。
实现分布式事务的几种方式。
第一阶段：正常情况下的操作过程如下：
在第一阶段，主要是事务管理者（经理）发起事务，让各个事务资源方（职员甲乙）确认资源是否满足，并做预处理（冻结）。资源方的操作有可能失败也可能成功。如，张三账户不足5元钱，没办法冻结，就是失败。资源方把操作结果反馈给事务管理者。
异常情况下的操作过程如下：
如果预提交过程中出现任何问题，导致事务不能执行。将会通知资源方进行撤销预提交操作。
第二阶段：如果是职员甲和职员乙都告诉经理，操作成功了。
这个时候，张三账户上的金额是25元。李四账户上的金额是35元。
如果出现异常，操作过程如下：
这个时候，张三账户上的金额是30元。李四账户上的金额也是30元。
总而言之，事务的执行会分为预提交和提交两步进行。任何一个小操作出问题，导致事务不能完成，将会进行回滚操作。
两阶段提交需要注意的
两阶段提交，要有一个事务管理者协调各方的操作。各方对资源的占用要到整个事务结束后才能释放。这样会影响事务的效率。当并发量大的时候，系统的性能会严重下滑。
事务管理者和资源方存在通信。有可能存在通信不通畅。如，职员甲接受到扣钱的命令后，职员甲扣完了钱。由于电话故障等原因，导致没办法通知经理已经操作成功。因此，各方还要处理通信超时问题。
整个流程需要事务管理者协调各个资源方进行操作。但是，事务管理者可能出现问题。导致没办法进行协调。如，经理生病了。
注意幂等性问题。可能存在对资源方重复调用的情况。这种情况下，资源方被调用多次和调用一次的效果要一样。如上例中，经理第二次通知职员甲扣5元的时候，职员甲要像上次一样，告诉经理扣款已经完成。但是，职员甲不能再进行扣款的动作。
基于消息实现
基于消息的实现大概过程如下：
基于消息的分布式事务实现中，引入了消息中间件（助理），负责消息的传递和事务执行状态的询问。这样就降低了系统间的耦合度。
为什么职员甲在进行扣款前，要告诉助理？主要是怕自己扣款成功了，又忘记告诉助理。这个时候，助理也就没办法通知职员乙操作了。告诉助理后，如果职员甲忘记了，助理可以询问职员甲，是否执行成功。进而决定是否该通知职员乙进行加钱操作。
如果职员甲扣款失败，则应该通知助理。助理在这种情况下，就不英再通知职员乙加钱。
基于消息实现的问题
基于消息的分布式事务实现，讲究的是最终一致性。也即所有的本地事务执行完毕后，整个状态的一致。
整个事务一般不会有回滚操作。如，当职员乙操作失败的时候，职员应该是再次通知职员乙重试。
引用
https://www.cnblogs.com/printN/p/6404776.html
https://baijiahao.baidu.com/s?id=1561633860372149&wfr=spider&for=pc
https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BA%8B%E5%8A%A1/9744607
