忘川彼岸|我只是下了个订单,鬼知道我在微服务里经历了什么?( 五 )
在分布式系统中 , 我们往往追求的是可用性 , 它的重要性比一致性要高 , 那么如何实现高可用 , 这里又有一个理论 , 就是 BASE 理论 , 它给 CAP 理论做了进一步的扩充 。
BASE 理论
BASE 理论指出:
- Basically Available(基本可用)
- Soft state(软状态)
- Eventually consistent(最终一致性)
好了 , 说了一大顿理论 , 程序员们都等急了 , 赶快来看看分布式事务的解决方案有哪些 , 可以进行接下去的 Coding...
来吧 , 讨论技术方案:
几个方案拿出来了 , 因为我们不是专门来讲解分布式事务的机制和原理 , 主要还是来做分布式事务的技术选型 。
先排除掉我们应该不会选择的方案 , 一个是 XA 两阶段提交 , 这个在很多传统型公司会被使用 , 但不适合互联网微服务的分布式系统 , 锁定资源时间长 , 性能影响大 , 排除 。
另一个是阿里的 GTS , 并没有开源 , 目前已经开源了 Fescar , 不过目前尚缺少调研 , 可能在下个阶段研究后会使用 , 目前先排除 。
剩下的是 TCC 和 MQ 消息事务两种 。
MQ 消息事务:RocketMQ
先说说 MQ 的分布式事务 , RocketMQ 在 4.3 版本已经正式宣布支持分布式事务 , 在选择 RokcetMQ 做分布式事务请务必选择 4.3 以上的版本 。
事务消息作为一种异步确保型事务 ,将两个事务分支通过 MQ 进行异步解耦 , RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论 , 整体交互流程如下图所示:
这个时候我们基本可以认为 , 只有 MQ 发送方自己的本地事务执行完毕 , 那么 MQ 的订阅方必定百分百能够接收到消息 , 我们再对下单减库存的步骤进行改造 。
这里涉及到一个异步化的改造 , 我们理一下 , 如果是同步流程中的各个步骤:
- 查看商品详情(或购物车)
- 计算商品价格和目前商品存在库存(生成订单详情)
- 商品扣库存(调用商品库存服务)
- 订单确认(生成有效订单)
商品服务接受到 orderCreate 消息后就执行扣减库存的操作 , 注意?? , 这里可能会有一些不可抗的因素导致扣减库存失败 。
无论成功或失败 , 商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中 , 订单服务会订阅扣减库存的结果 。
订单服务收到消息后有两种可能:
- 如果扣减库存成功 , 将订单状态改为 “确认订单”, 下单成功 。
- 如果扣减库存失败 , 将订单状态改为 “失效订单”, 下单失败 。
这种模式将确认订单的流程变成异步化 , 非常适合在高并发的使用 , 但是 , 切记了 , 这个需要前端用户体验的一些改变 , 要配合产品来涉及流程 。
- |申花希望租借格德斯遭鲁能拒绝,马丁内斯尚未加盟只是试训
- 忘川彼岸|启迪设计中标微软(中国)苏州科技园区二期办公楼项目设计总包
- UZI|Uzi玩游戏输给邹市明?二人只是小打小闹,真打还得看寒夜毒纪
- 卡玛拉|《复仇者联盟》:不只是游戏,更是一部优秀的电影
- 伽德鲁|《没落要塞》如果一切只是一场游戏,那么活着是否还有意义?末日中的假象看似命运的安排其实是一场游戏活着是否还有意义
- 澎湃新闻|签协议时不知要搬驻以使馆?塞尔维亚总统:只是再检查一遍
- 美国有线电视新闻网|《大西洋月刊》总编辑:有关特朗普骂阵亡美军的报道,只是“冰山一角”
- 环球网|大西洋月刊总编辑:特朗普骂阵亡美军的报道,只是“冰山一角”
- 环球网|《大西洋月刊》总编辑:有关特朗普骂阵亡美军是“失败者”的报道,只是“冰山一角”
- 帅不过三秒|求赵露思别再穿娃娃裙了,裙摆只是加了层褶,腿就显瘦到我崩溃