vinic-xxm

CAP 定理

CAP 必须满足以下的 3 个属性:

一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在 C 和 A 之间做出选择。

简单的来说,在一个分布式系统中,最多能支持上面的两种属性。但显然既然是分布式注定我们是必然要进行分区,既然分区,我们就无法百分百避免分区的错误。因此,我们只能在一致性和可用性去作出选择。

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

BASE 理论

Basically Available(基本可用)

Soft state(软状态)

Eventually consistent(最终一致性)

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。

MQ消息事务-RocketMQ

先说说MQ的分布式事务,RocketMq在4.3版本已经正式宣布支持分布式事务,在选择Rokcetmq做分布式事务请务必选择4.3以上的版本。

事务消息作为一种异步确保型事务, 将两个事务分支通过 MQ 进行异步解耦,RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论,整体交互流程如下图所示:

这个时候我们基本可以认为,只有MQ发送方自己的本地事务执行完毕,那么MQ的订阅方必定百分百能够接收到消息,我们再对下单减库存的步骤进行改造:

这里涉及到一个异步化的改造,我们理一下如果是同步流程中的各个步骤

查看商品详情(或购物车)

计算商品价格和目前商品存在库存(生成订单详情)

商品扣库存(调用商品库存服务)

订单确认(生成有效订单)

订单创建完成后,发布一个事件“orderCreate” 到消息队列中,然后由MQ转发给订阅该消息的服务,因为是基于消息事务,我们可以认为订阅该消息的商品模块是百分百能收到这个消息的。


商品服务接受到orderCreate消息后就执行扣减库存的操作,注意,这里可能会有一些不可抗的因素导致扣减库存失败,无论成功或失败,商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中,订单服务会订阅扣减库存的结果。

订单服务收到消息后有两种可能:

如果扣减库存成功,将订单状态改为 “确认订单” ,下单成功

如果扣减库存失败,将订单状态改为 “失效订单” ,下单失败


这种模式将确认订单的流程变成异步化,非常适合在高并发的使用,但是,切记了,这个需要前端用户体验的一些改变,要配合产品来涉及流程。

完美,使用MQ分布式事务就可以解决调一致性问题
MQ消息事务方案的风险了解一下

上面使用MQ的方式确实是可以完成A和B操作,但是A和B并不是严格一致性,而是最终一致性,我们牺牲掉严格一致性,换来性能的提升,这种很适合在大促高并发场景总使用,但是如果B一直执行不成功,那么一致性也会被破坏,后续应该考虑到更多的兜底方案,方案越细系统就将越复杂。

分类:

技术点:

相关文章: