见有聊点分布式事务，求解一般微服务方案

• 主 資深大佬 : jiurenmeng

  例： 微服务：商城、商品、订单 备注：都为单独服务和数据
  rn

  “`
  try{
  //商品服务 处理商品扣库存
  //订单服务 订单生成（ error ）？
  return;
  }catch($e) {
  // ？怎么处理合适
  }
  “`

  rn
  只有单体应用开发经验，不知道怎么排版

• 資深大佬 : realpg

  每个独立的 operation 都有对应的撤销方法

• 資深大佬 : zhgg0

  1 、生成订单号
  2 、预扣商品库存
  3 、订单生成
  4 、真的扣库存

  订单服务提供反查功能，根据订单号查是否成功

  各种状况：
  1 和 2 失败没任何影响；
  3 那步挂了，库存服务过段时间反查订单是否成功，没成功的话将库存恢复；
  4 那步挂了，库存服务过段时间反查订单是否成功，成功的话变成真的扣库存。

• 資深大佬 : xuanbg

  要搞微服务，先搞 devops 。git 用起来，jenkins 自动化容器化部署搞出来先。同时 elk 或者 efk 搞起来，不要捞个日志还费死个劲。然后 maven 私服什么的也搞起来。。。

  上面这些搞好了，然后把例如用户中心、消息中心这些基础服务拆出来搞起来。

  最后，你去搞业务就非常轻松了。如果一上来就拆业务，累死你也搞不好微服务。

• 資深大佬 : love

  那撤销方法中间机器死机了呢，数据不一致了

• 資深大佬 : xuanbg

  @realpg
  @love 基本没人会这么搞，分布式系统大多采用的是最终一致性。也就是说如果出错，不是回滚数据，而是用消息队列进行补偿来保证数据的一致性。当然补偿也不能保证百分百成功，最终还可以通过肉偿(人工处理)来保证一致性。

• 資深大佬 : singerll

  看到微服务就想笑，我们公司的微服务几十个 jar 包，挂一个就全挂。真不知道研发脑子里面想的啥。

• 資深大佬 : Leigg

  @singerll 那是技术问题

• 資深大佬 : Leigg

  最终一致性，善用 mq 和定时任务