减库存可以采用同步调用(商品微服务提供接口,通过Feign调用),也可以采用异步调用(通过RabbitMq),我们采用同步调用,接下来我们来分析分析原因。
若采用异步调用的方式,我们要进行减库存,只需向RabbitMq中发送消息即可,后续我们不管,但是否减库存成功我们不得而知。若库存不足,则减库存失败,但是订单微服务中并不知道减库存失败,因此事务不会回滚,这就是分布式事务问题 (跨服务的事务)。我们写的减库存业务从订单微服务跨越到了商品微服务,而事务是由Spring来管理的,两个tomcat两个Spring,两个事务本身没有任何关联,但是却是一个事务(减库存和创建订单应该一起完成),如果采用异步,一边微服务执行失败另一边微服务并不知道,破坏了事务的一致性 。
我们把异步调用变成同步调用,调用如果失败就会抛出异常,事务自然回滚(减库存操作只能放在创建订单业务的最后,因为减库存执行失败,事务自然会回滚,订单也就不会创建成功,但是如果刚开始就做减库存操作,那如果订单创建失败库存无法回滚,导致丢失库存数据),但当业务更复杂时(比如:优惠券功能、积分),有好几个服务之间调用。这时我们把那个放在最后呢?哪个放在最后都不行,这时候就要解决分布式事务问题了。
解决分布式事务问题:
-
2PC(两阶段提交):第一阶段(执行阶段):当“我”创建订单时,“我”向所有“我”要调用的微服务发一个请求,告诉他们开始执行,执行完毕后向“我”返回一条消息,告诉“我”你是执行成功了还是失败了;第二阶段:如果上一阶段所有人都执行成功,然后“我”会再发一条消息告诉所有人让其提交,如果第一阶段有一个人执行失败,则通知所有人都回滚
- 实现复杂、还会用到一些异步通信的手段(比如:MQ),在业务执行