互联网电商大厂的分布式事务使用案例

Posted 2022-12-16 JavaEdge.

事务的原子性、持久性可确保在一个事务内，更新多条数据都成功/失败。在一个系统内部，我们可以使用数据库事务来保证数据一致性。那如果一笔交易，涉及到跨多个系统、多个数据库的时候，用单一的数据库事务就没办法解决了。

在之前大系统时代，普遍的做法：设计时尽量避免这种跨系统跨数据库的交易。

但现在技术趋势是云原生和微服务，大系统被打散成多个微服务，每个微服务独立部署并拥有自己的数据库，大数据库也被打散成多个小数据库。跨越微服务和数据库的交易就成为普遍情况，不可避免要面对跨系统的数据一致性问题。

如何解决这种跨系统、跨数据库的数据一致性问题？分布式事务。但它可不像数据库事务，在开始和结尾分别加上begin和commit，剩下的问题数据库都可以帮我们搞定。

分布式环境，一个交易将会被分布到不同系统，多个微服务进程内执行计算，在多个数据库中执行数据更新操作，这比数据库事务支持的单进程单数据库场景复杂多。所以，并没有什么分布式事务服务或组件能在分布式环境下，提供接近数据库事务的数据一致性保证。

如何用分布式事务的方法，解决微服务系统中实际面临的分布式数据一致性问题呢？

1 什么是分布式事务

没有一种分布式事务的服务或组件，能简单解决分布式系统下的数据一致性问题。使用分布式事务时，更多情况是，用分布式事务理论指导设计和开发，自行解决数据一致性问题。即要解决分布式一致性问题，须掌握分布式事务实现原理。

即使是数据库事务，它考虑到性能因素，大部分情况下不能也不需要百分之百地实现ACID，所以才有事务隔离级别。

分布式事务也是事务，也需遵从ACID。但实际分布式系统中，因为须兼顾性能、高可用，不可能完全满足ACID。分布式事务实现都是“残血版”事务，相比数据库事务，更加“残血”。

分布式事务的解决方案如：2PC、3PC、TCC、Saga和本地消息表。强、弱项都不一样，适用场景也不一样。2PC和本地消息表较贴近于日常开发的业务系统。

2 2PC：订单与优惠券的数据一致性问题

2PC，二阶段提交。

购物下单时，若使用了优惠券，订单系统、优惠券系统都要更新自己的数据，才能完成“在订单中使用优惠券”的操作。

订单系统需：

1. 在“订单优惠券表”中写入订单关联的优惠券数据
2. 在“订单表”中写入订单数据

订单系统内两个操作的一致性问题可直接使用DB事务。

促销系统需要操作就比较简单，把刚使用的那张优惠券的状态更新成“已使用”。

需要这两个系统的数据更新操作保持一致，都更新成功/失败。

2PC怎么解决问题

2PC引入一个

事务协调者

来协调订单系统和促销系统，协调者对客户端提供一个完整的“使用优惠券下单”的服务，在这个服务内部，协调者再分别调用订单、促销的相应服务。

二阶段

准备阶段、提交阶段：

准备阶段

协调者分别给订单系统、促销系统发“准备”命令，订单、促销系统收到准备命令后，开始执行准备操作。准备阶段都需要做哪些事儿呢？除了提交数据库事务以外的所有工作，都要在准备阶段完成。如订单系统在准备阶段需完成：

1. 在订单库开启一个DB事务
2. 在“订单优惠券表”写入这条订单的优惠券记录
3. 在“订单表”中写入订单数据

到这里，我们没提交订单DB的事务，最后给事务协调者返回“准备成功”。

同理，促销服务在准备阶段，需在促销库开启一个DB事务，更新优惠券状态，但暂不提交该DB事务，给协调者返回“准备成功”。

协调者收到两个系统“准备成功”的响应后，开始进入第二阶段。等两个系统都准备好，进入

提交阶段

协调者再给这两个系统发“提交”命令，每个系统提交自己的DB事务，然后给协调者返回“提交成功”响应。

协调者收到所有响应后，给客户端返回成功响应，整个分布式事务结束。

该过程的时序图

这都是理想的正常情况

3 异常了怎么办？

还分两个阶段

3.1 准备阶段

若任一步错误或超时，协调者就会给两个系统发送“回滚事务”请求。每个系统在收到请求之后，回滚自己的DB事务，分布式事务执行失败，两个系统的DB事务都回滚了，相关的所有数据回滚到分布式事务执行之前的状态，就像这个分布式事务没有执行一样。

3.1.1 异常情况时序图

若准备阶段成功，则进入

3.2 提交阶段

这就只剩一条路，整个分布式事务只能成功，不能失败。

若该阶段发生如下异常：

网络传输失败

需反复重试，直到提交成功。

宕机

包括两个DB宕机或订单服务、促销服务节点宕机，还是可能出现订单库完成提交，但促销库因宕机自动回滚，导致数据不一致。但因提交的过程很简单，执行很快，出现这种情况的概率很小，所以，从实用角度，2PC实际的数据一致性还是很好的。

实现2PC时，没必要单独启动一个事务协调服务，该协调服务的工作最好和订单服务或优惠券服务放在同一进程，好处是：

• 参与分布式事务的进程更少，故障点就更少，稳定性更好
• 减少远程调用，性能也更好

2PC是一种强一致设计，它可保证原子性、隔离性。只要2PC事务完成，订单库、促销库中的数据一定是一致状态，即都成功/失败。

所以2PC适合那些对数据一致性要求较高场景，如订单优惠券，若一致性保证不好，有可能会被黑产利用，一张优惠券反复使用！

2PC的缺陷

整个事务的执行过程，需阻塞服务端的线程和数据库的会话，所以，2PC在并发场景下的性能不太高。

协调者是个单点，一旦协调者宕机，就会导致订单库或促销库的事务会话一直卡在等待提交阶段，直到事务超时自动回滚。

卡住的这段时间，DB可能会锁住一些数据，服务中会卡住一个数据库连接和线程，这些都会造成系统性能严重下降，甚至整个服务被卡住。

适用场景

所以，只有在需强一致、并发量不大，才考虑2PC。

3 本地消息表：订单与购物车的数据一致性问题

2PC适用场景很窄，更多情况下，只要保证数据最终一致。如购物流程中，用户在购物车选好商品，点击“去结算”按钮，进入订单页面创建一个新订单。这过程，我们的系统做了：

1. 订单系统需创建一个新订单，订单关联的商品就是购物车中选择的那些商品
2. 创建订单成功后，购物车系统需将订单中的这些商品从购物车删掉

这也是分布式事务问题，创建订单、清空购物车两个数据更新操作需保证都成功/失败。但清空购物车对一致性要求没扣减优惠券那么高，订单创建成功后，晚几s再清空购物车，完全可接受。只要保证经过小延迟后，最终的订单数据和购物车数据保持一致。

3.1 适用场景

分布式最终一致性问题。

3.2 实现思路

订单服务在收到下单请求后，正常使用订单库的事务去更新订单数据。执行这个DB事务过程中，在本地记录一条消息，即一个日志，内容：“清空购物车”。因为这日志记录在本地，不牵涉分布式问题，那这就是普通的单机事务，那我们就能让订单库的事务，来保证记录本地消息和订单库的一致性。完成这步后，就能给客户端返回成功响应。

然后，再用一个异步服务，读取刚记录的清空购物车的本地消息，调用购物车系统的服务清空购物车。购物车清空后，把本地消息的状态更新成已完成。异步清空购物车这个过程，若操作失败，可重试。最终，可保证订单系统和购物车系统它们的数据一致。

这里的本地消息表，可选择：

• 存在订单库

  相对来说，放在订单库更简单

• 也可用文件的形式，保存在订单服务所在服务器的本地磁盘

RocketMQ提供事务消息，就是本地消息表思想的实现。使用事务消息可达到和本地消息表一样的最终一致性，相比自己实现本地消息表，使用更简单。

本地消息表只满足D（持久性），A（原子性）C（一致性）、I（隔离性）都较差，但

优点突出

实现简单

在单机事务的基础上稍加改造，即可实现分布式事务。

性能非常好

和单机事务的性能几乎无差。在这基础，还提供大部分情况下都能接受的“数据最终一致性”的保证。

所以，本地消息表是更实用的分布式事务实现。即使能接受数据最终一致，本地消息表也不是银弹。

使用前提

异步执行的那部分操作，不能有依赖资源。如下单时，除了要清空购物车，还要锁定库存。

库存系统锁定库存的操作，虽能接受数据最终一致，但锁定库存有前提：库存中得有货。这就不适合本地消息表，不然就会出现用户下单成功后，系统的异步任务去锁定库存时，因为缺货导致锁定失败。这种case就很难处理。

4 总结

对订单和优惠券这种需强一致的分布式事务场景，可采用2PC。优点强一致，但性能和可用性都有缺陷。

本地消息表适用性更广，虽在数据一致性有所牺牲，只满足最终一致性，但有更好性能，实现简单，系统稳定性也很好。

无论是哪种分布式事务方法，其实都是把一个分布式事务，拆分成多个本地事务。本地事务可以用DB事务，那分布式事务就专注于解决如何让这些本地事务保持一致。

遇到分布式一致性问题的时候，也要基于这个思想来考虑问题，再结合实际的情况选择分布式事务实现。