文档

应用场景

更新时间:

分布式事务可应用在多个涉及数据库操作的领域,尤其在金融领域可以做到全场景的覆盖与落地验证,包括:

  • 支付与转账、账务:对于吞吐量有很高的要求

  • 金融与理财:往往涉及的金额较大,所以对于产品的稳定性要求非常高

  • 保险与监管报送:参与方多,业务复杂度高是该类业务的典型特征

典型的应用场景如下:

分库分表后的跨数据库分布式事务

例如支付宝的交易服务,随着业务规模的增大,单个交易流水表已经不能满足业务需求,需要通过分库分表实现数据水平拆分。但是水平拆分后,单表的数据被分散到多个库的表中,原来对单表多行数据进行的变更,可能会变为对多库多表的数据变更,即单机本地事务变成了分布式事务。

使用分布式事务能够轻易获得分布式事务处理能力。如果交易服务使用数据访问代理来分库分表,虽然数据访问代理本身不支持分布式事务,但是分布式事务可以轻松和数据访问代理集成,使得数据访问代理具备分布式事务的处理能力,解决分库分表后的跨库分布式事务问题。

cross-db-1cross-db-2

跨服务的分布式事务

例如,支付宝核心链路上的三个服务为:交易、支付、账务。当用户发起一笔交易时:

  1. 首先访问交易服务,创建交易订单。

  2. 然后交易服务调用支付服务为该交易创建支付订单,执行收款动作。

  3. 最后支付服务调用账务服务记录账户流水和记账。

为了保证三个服务一起完成一笔交易(要么同时成功,要么同时失败),可以使用分布式事务将这三个服务放在一个分布式事务中,从而保证服务间调用的数据一致性。

cross-service

混合分布式事务

有些系统在使用数据库保证系统内数据一致的同时,也会使用消息队列作为和其他系统间的消息传递,完成不同系统间的数据一致。

例如会员注册服务和邮件发送服务,当用户注册会员成功,需要给用户发送一封邮件,告诉用户注册成功,并提示用户激活该会员。但要注意两点:

  • 如果用户注册成功,一定要给用户发送一封邮件;

  • 如果用户注册失败,一定不能给用户发送邮件。

因此,这同样需要会员服务和邮件服务保证原子性(要么都执行,要么都不执行)。不一样的是,邮件服务只是一种被动型的业务,并不影响用户是否能够注册成功,它只需要在用户注册成功以后发送邮件给用户即可,邮件服务不需要参与到会员服务的活动决策中。因此,可以使用消息队列来解耦会员和邮件服务。

对于此种业务场景,分布式事务可以将会员服务、消息队列组成分布式事务模型,保证事务原子性。然后通过消息队列的可靠特性,确保消息一定能够被邮件服务消费,从而使得会员与邮件服务在同一个分布式事务中。同时,邮件服务也不会影响会员服务的执行过程,只在会员服务执行成功后被动接收发送邮件的请求。

hybrid
  • 本页导读 (0)
文档反馈