订单业务减库存 -- 分布式事务问题与高并发解决线程安全问题

本文探讨了在分布式事务环境下,同步和异步调用在减库存操作中的应用及其问题。同步调用可以避免事务一致性问题,但可能导致性能下降。介绍了2PC、TCC等分布式事务解决方案,并指出它们各自的优缺点。在高并发场景下,简单的加锁策略(如synchronized)不再适用,推荐使用分布式锁(如Zookeeper或Redis)。然而,为了避免锁带来的性能损失,提出了在SQL中直接进行条件判断的乐观锁策略,以提高并发性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

减库存可以采用同步调用(商品微服务提供接口,通过Feign调用),也可以采用异步调用(通过RabbitMq),我们采用同步调用,接下来我们来分析分析原因。

若采用异步调用的方式,我们要进行减库存,只需向RabbitMq中发送消息即可,后续我们不管,但是否减库存成功我们不得而知。若库存不足,则减库存失败,但是订单微服务中并不知道减库存失败,因此事务不会回滚,这就是分布式事务问题 (跨服务的事务)。我们写的减库存业务从订单微服务跨越到了商品微服务,而事务是由Spring来管理的,两个tomcat两个Spring,两个事务本身没有任何关联,但是却是一个事务(减库存和创建订单应该一起完成),如果采用异步,一边微服务执行失败另一边微服务并不知道,破坏了事务的一致性

我们把异步调用变成同步调用调用如果失败就会抛出异常,事务自然回滚(减库存操作只能放在创建订单业务的最后,因为减库存执行失败,事务自然会回滚,订单也就不会创建成功,但是如果刚开始就做减库存操作,那如果订单创建失败库存无法回滚,导致丢失库存数据),但当业务更复杂时(比如:优惠券功能、积分),有好几个服务之间调用。这时我们把那个放在最后呢?哪个放在最后都不行,这时候就要解决分布式事务问题了。


解决分布式事务问题:
  • 2PC(两阶段提交):第一阶段(执行阶段):当“我”创建订单时,“我”向所有“我”要调用的微服务发一个请求,告诉他们开始执行,执行完毕后向“我”返回一条消息,告诉“我”你是执行成功了还是失败了;第二阶段:如果上一阶段所有人都执行成功,然后“我”会再发一条消息告诉所有人让其提交,如果第一阶段有一个人执行失败,则通知所有人都回滚

    • 实现复杂、还会用到一些异步通信的手段(比如:MQ),在业务执行
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值