本文探讨了在分布式事务环境下，同步和异步调用在减库存操作中的应用及其问题。同步调用可以避免事务一致性问题，但可能导致性能下降。介绍了2PC、TCC等分布式事务解决方案，并指出它们各自的优缺点。在高并发场景下，简单的加锁策略（如synchronized）不再适用，推荐使用分布式锁（如Zookeeper或Redis）。然而，为了避免锁带来的性能损失，提出了在SQL中直接进行条件判断的乐观锁策略，以提高并发性能。
减库存可以采用同步调用（商品微服务提供接口，通过Feign调用），也可以采用异步调用（通过RabbitMq），我们采用同步调用，接下来我们来分析分析原因。
若采用异步调用的方式，我们要进行减库存，只需向RabbitMq中发送消息即可，后续我们不管，但是否减库存成功我们不得而知。若库存不足，则减库存失败，但是订单微服务中并不知道减库存失败，因此事务不会回滚，这就是分布式事务问题 （跨服务的事务）。我们写的减库存业务从订单微服务跨越到了商品微服务，而事务是由Spring来管理的，两个tomcat两个Spring，两个事务本身没有任何关联，但是却是一个事务（减库存和创建订单应该一起完成），如果采用异步，一边微服务执行失败另一边微服务并不知道，破坏了事务的一致性 。
我们把异步调用变成同步调用，调用如果失败就会抛出异常，事务自然回滚（减库存操作只能放在创建订单业务的最后，因为减库存执行失败，事务自然会回滚，订单也就不会创建成功，但是如果刚开始就做减库存操作，那如果订单创建失败库存无法回滚，导致丢失库存数据），但当业务更复杂时（比如：优惠券功能、积分），有好几个服务之间调用。这时我们把那个放在最后呢？哪个放在最后都不行，这时候就要解决分布式事务问题了。
解决分布式事务问题：
-
2PC（两阶段提交）：第一阶段（执行阶段）：当“我”创建订单时，“我”向所有“我”要调用的微服务发一个请求，告诉他们开始执行，执行完毕后向“我”返回一条消息，告诉“我”你是执行成功了还是失败了；第二阶段：如果上一阶段所有人都执行成功，然后“我”会再发一条消息告诉所有人让其提交，如果第一阶段有一个人执行失败，则通知所有人都回滚
- 实现复杂、还会用到一些异步通信的手段（比如：MQ），在业务执行
最低0.47元/天 解锁文章
扫一扫
756
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
