谷粒商城-高级-74 -商城业务-分布式事务-最终一致性库存解锁逻辑

一、Seata的不足

Seata的AT模式是二阶段提交协议(2PC),第一阶段将本地事务直接提交,第二阶段想要回滚的时候,是通过回滚日志(日志表)做的反向补偿,数据库原来是多少又改了回来。

Seata应用场景:后台管理系统,比如添加商品,优惠、库存、积分、会员要成功都成功,要失败都失败,对于并发性能不高的可以使用Seata来处理分布式事务。

如果并发性能要求很高的,比如下单,则需要使用最终一致性,RMQ发消息,保证消息的可靠性(发送端和接收端确认),不能达到强一致性,但能达到软柔性事务的最终一致性。

下单属于高并发场景,为了保证高并发,不推荐使用seata,Seata用了很多锁机制,因为是加锁,相当于把并发变为串行了,如果多个订单下来,就得进行排队,等待上一个人处理完了,释放了锁,才能继续下单,这样系统可能就没法用了,提升不了效率,可以发消息给库存服务。

二、高并发场景

在高并发场景下,不考虑 2PC 和 TCC 模式(这两种属于刚性事务),可以使用 最大努力通知型方案可靠消息+最终一致性方案,这两种是通过消息来实现的,并且都是柔性事务。

为了保证高并发,库存服务自己回滚,可以发消息给库存服务。库存服务本身也可以使用自动解锁模式,要参与消息队列。

file

在锁库存的时候,需要给数据库增加记录,锁的数量和SKU,以及仓库,如果锁失败,库存锁表里边没有这条记录,可以使用定时任务来处理,不过使用定时任务来处理,是非常麻烦的事情,可以使用延时队列来处理,延时队列做一个定时工作。

file

为者常成,行者常至