分布式事务可应用在多个涉及数据库操作的领域，尤其在金融领域可以做到全场景的覆盖与落地验证，包括：
支付与转账、账务：对于吞吐量有很高的要求
金融与理财：往往涉及的金额较大，所以对于产品的稳定性要求非常高
保险与监管报送：参与方多，业务复杂度高是该类业务的典型特征
典型的应用场景如下：
分库分表后的跨数据库分布式事务
例如支付宝的交易服务，随着业务规模的增大，单个交易流水表已经不能满足业务需求，需要通过分库分表实现数据水平拆分。但是水平拆分后，单表的数据被分散到多个库的表中，原来对单表多行数据进行的变更，可能会变为对多库多表的数据变更，即单机本地事务变成了分布式事务。
使用分布式事务能够轻易获得分布式事务处理能力。如果交易服务使用数据访问代理来分库分表，虽然数据访问代理本身不支持分布式事务，但是分布式事务可以轻松和数据访问代理集成，使得数据访问代理具备分布式事务的处理能力，解决分库分表后的跨库分布式事务问题。
跨服务的分布式事务
例如，支付宝核心链路上的三个服务为：交易、支付、账务。当用户发起一笔交易时：
首先访问交易服务，创建交易订单。
然后交易服务调用支付服务为该交易创建支付订单，执行收款动作。
最后支付服务调用账务服务记录账户流水和记账。
为了保证三个服务一起完成一笔交易（要么同时成功，要么同时失败），可以使用分布式事务将这三个服务放在一个分布式事务中，从而保证服务间调用的数据一致性。
混合分布式事务
有些系统在使用数据库保证系统内数据一致的同时，也会使用消息队列作为和其他系统间的消息传递，完成不同系统间的数据一致。
例如会员注册服务和邮件发送服务，当用户注册会员成功，需要给用户发送一封邮件，告诉用户注册成功，并提示用户激活该会员。但要注意两点：
如果用户注册成功，一定要给用户发送一封邮件；
如果用户注册失败，一定不能给用户发送邮件。
因此，这同样需要会员服务和邮件服务保证原子性（要么都执行，要么都不执行）。不一样的是，邮件服务只是一种被动型的业务，并不影响用户是否能够注册成功，它只需要在用户注册成功以后发送邮件给用户即可，邮件服务不需要参与到会员服务的活动决策中。因此，可以使用消息队列来解耦会员和邮件服务。
对于此种业务场景，分布式事务可以将会员服务、消息队列组成分布式事务模型，保证事务原子性。然后通过消息队列的可靠特性，确保消息一定能够被邮件服务消费，从而使得会员与邮件服务在同一个分布式事务中。同时，邮件服务也不会影响会员服务的执行过程，只在会员服务执行成功后被动接收发送邮件的请求。
