> 文档中心 > 互联网电商大厂的分布式事务使用案例

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

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

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

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

如何解决这种跨系统、跨数据库的数据一致性问题?分布式事务。但它可不像数据库事务,在开始和结尾分别加上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事务,然后给协调者返回“提交成功”响应。

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

该过程的时序图

img

这都是理想的正常情况

3 异常了怎么办?

还分两个阶段

3.1 准备阶段

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

3.1.1 异常情况时序图

img

若准备阶段成功,则进入

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事务,那分布式事务就专注于解决如何让这些本地事务保持一致。

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