江苏龙网

  1. 首页 > 人文 > >

忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 五 )


在分布式系统中 ， 我们往往追求的是可用性 ， 它的重要性比一致性要高 ， 那么如何实现高可用 ， 这里又有一个理论 ， 就是 BASE 理论 ， 它给 CAP 理论做了进一步的扩充 。
BASE 理论
BASE 理论指出：

  • Basically Available(基本可用)
  • Soft state(软状态)
  • Eventually consistent(最终一致性)
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果 ， 理论的核心思想就是：我们无法做到强一致 ， 但每个应用都可以根据自身的业务特点 ， 采用适当的方式来使系统达到最终一致性 。
好了 ， 说了一大顿理论 ， 程序员们都等急了 ， 赶快来看看分布式事务的解决方案有哪些 ， 可以进行接下去的 Coding...
来吧 ， 讨论技术方案：
忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？几个方案拿出来了 ， 因为我们不是专门来讲解分布式事务的机制和原理 ， 主要还是来做分布式事务的技术选型 。
先排除掉我们应该不会选择的方案 ， 一个是 XA 两阶段提交 ， 这个在很多传统型公司会被使用 ， 但不适合互联网微服务的分布式系统 ， 锁定资源时间长 ， 性能影响大 ， 排除 。
另一个是阿里的 GTS ， 并没有开源 ， 目前已经开源了 Fescar ， 不过目前尚缺少调研 ， 可能在下个阶段研究后会使用 ， 目前先排除 。
剩下的是 TCC 和 MQ 消息事务两种 。
MQ 消息事务：RocketMQ
先说说 MQ 的分布式事务 ， RocketMQ 在 4.3 版本已经正式宣布支持分布式事务 ， 在选择 RokcetMQ 做分布式事务请务必选择 4.3 以上的版本 。
事务消息作为一种异步确保型事务 ，将两个事务分支通过 MQ 进行异步解耦 ， RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论 ， 整体交互流程如下图所示：
忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？这个时候我们基本可以认为 ， 只有 MQ 发送方自己的本地事务执行完毕 ， 那么 MQ 的订阅方必定百分百能够接收到消息 ， 我们再对下单减库存的步骤进行改造 。
这里涉及到一个异步化的改造 ， 我们理一下 ， 如果是同步流程中的各个步骤：
  • 查看商品详情(或购物车)
  • 计算商品价格和目前商品存在库存(生成订单详情)
  • 商品扣库存(调用商品库存服务)
  • 订单确认(生成有效订单)
订单创建完成后 ， 发布一个事件“orderCreate” 到消息队列中 ， 然后由 MQ 转发给订阅该消息的服务 ， 因为是基于消息事务 ， 我们可以认为订阅该消息的商品模块是百分百能收到这个消息的 。
忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？
忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？商品服务接受到 orderCreate 消息后就执行扣减库存的操作 ， 注意?? ， 这里可能会有一些不可抗的因素导致扣减库存失败 。
无论成功或失败 ， 商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中 ， 订单服务会订阅扣减库存的结果 。
订单服务收到消息后有两种可能：
  • 如果扣减库存成功 ， 将订单状态改为 “确认订单”， 下单成功 。
  • 如果扣减库存失败 ， 将订单状态改为 “失效订单”， 下单失败 。

忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？这种模式将确认订单的流程变成异步化 ， 非常适合在高并发的使用 ， 但是 ， 切记了 ， 这个需要前端用户体验的一些改变 ， 要配合产品来涉及流程 。


推荐阅读


上一篇：同仁堂董事长王贵平：切实履行国企责任担当

下一篇：动解｜河南早产儿“死而复生”引关注，“死胎”如何判断？