E-Commerce中分布式事务的研究

Posted 2021-04-25 博克软件

分布式事务主要指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上。简单的说，就是一次大的操作是由小操作组成，这些小操作分布于不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功、要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

1. 分布式事务的应用场景

场景1 支付流程

最经典的案例是支付，当买家下完订单，完成支付，系统会对买家账户进行扣款，同时对卖家账户进行加钱，这个操作必须在一个事务里执行完成，要么全部成功，要么全部失败。而对于买家和卖家账户，他们分属于两个不同的系统，对应两个不同的数据库，这个时候必须引入分布式来对这个两个不同的数据库进行操作。

场景2 在线下单

另外一个常见的案例是在线下单，买家在电商系统下订单，往往涉及到两个操作，一个是扣除库存，第二个是更新订单状态，这边涉及到电商系统常见的库存系统和订单系统，他们都分属于两个不同的数据库，同样需要分布式事务来保证一致性。

2. 基于MQ的常见分布式事务解决方案

基于消息事务MQ，保证数据的最终一致性，所谓的消息事务就是基于消息中间件的两阶段提交，它是将本地事务和发送消息放在一个分布式事务里，保证本地操作成功并成功发送消息，或者两者都失败。

就上述两个分布式场景，我们做一些简单的分析：

场景1支付流程

a.  当买家下完订单，用户准备支付，系统向消息中间件发送预备消息，消息中间件接收并保存预备消息。

b.  本地事务开始检查买家账户余额是否足够，如果余额充足，本地完成扣款，事务提交

c.  系统向消息中间件发送确认消息

d.  卖家系统通过消息中间件，接收到消息中间件发送的买家扣款消息，卖家账户完成加钱操作，并提交事务

这里会涉及到几个例外情况发生

第一种情况：如果买家扣款失败，那么整个流程，包括卖家加钱操作都会失败

第二种情况：如果确认消息发送失败，买家扣款操作虽然执行成功，但是会被回滚

第三种情况：如果卖家加钱操作失败，系统会继续重试操作，直到加钱成功

场景2在线下订单

a.  用户完成下订单操作，订单系统往订单表插入数据，并记录日志；

b.  读取日志，发送确认消息到消息中间件；

c.  库存系统接收到消息，更新库存数据；

我们设想可能出现的情况

第一种情况：abc三者都正常执行，那么整个流程正常结束。

第二种情况：b超时，那么a需要重新发送确认消息到消息中间件，知道消息发送成功，如果一直失败，可能需要人为干预。

第三种情况：abc种有一个失败了，失败的服务利用MQ飞其他的服务发送消息，其他服务接收消息，查看本地事务日志，如果本地也失败，删除收到的消息，如果本地成功，则需要调用补偿借口进行补偿。

3. 总结

目前大部分的电商系统，都是利用MQ来实现系统最终一致性，可以较大的提高整个系统的性能，也能较好的处理大量数据的并发情况，当然本身具体是否使用MQ来实现一致性，还是需要根据具体业务场景来确定。