分布式事务

JAVA ZMAS 14℃ 0评论

什么是分布式事务

以前我们写项目的时候, 因为用的都是一个mysql数据库, mysql数据库当中innoDB引擎是支持ACID 事务特性的,能够满足我们的事务要求,但现在 分布式项目中,我们会有多个微服务处理不同业务 都是独立的进程, 数据库也都是相互独立, 但是呢 事务可能要横跨这些微服务, 比如订单功能, 如果 我支付订单成功 在订单微服务中 我需要改变订单状态, 在库存微服务中 需要减对应的库存, 在积分微服务中得加对应积分, 这是一个整体的事务 这种事务就是分布式事务

CAP理论

简单来说: C 一致性 A 可用性 P 分区容错 在分布式事务中我们只能够同时满足两个

熟悉 CAP 的人都知道,三者不能共有,如果感兴趣可以搜索 CAP 的证明,在分布式系统中,网络无法 100% 可靠,分区其实是一个必然现象。
如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证一致性,这个时候必须拒绝请求,但是 A 又不允许,所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构。
对于 CP 来说,放弃可用性,追求一致性和分区容错性,我们的 ZooKeeper 其实就是追求的强一致。
对于 AP 来说,放弃一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择,后面的 BASE 也是根据 AP 来扩展。
顺便一提,CAP 理论中是忽略网络延迟,也就是当事务提交时,从节点 A 复制到节点 B 没有延迟,但是在现实中这个是明显不可能的,所以总会有一定的时间是不一致。
同时 CAP 中选择两个,比如你选择了 CP,并不是叫你放弃 A。因为 P 出现的概率实在是太小了,大部分的时间你仍然需要保证 CA。
就算分区出现了你也要为后来的 A 做准备,比如通过一些日志的手段,是其他机器回复至可用。

Base理论

简单来说: 满足 AP 但对于C来说 要追求 最终一致 性

基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。
软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。

最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。

BASE 和 ACID 是相反的,它完全不同于 ACID 的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

2PC 二阶段分步提交

白话:各个服务在处理数据过程中,会进行预备提交操作, 预备操作 可以反映出 各个节点是否都能够提交,
预备操作如果成功的话,那么 事务协调器会执行每个数据库的 commit操作
如果 在预提交过程当中有一个节点不能够提交, 事务协调器会执行每个数据库的 roll back 操作

高大上:事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交。
事务协调器要求每个数据库提交数据,或者回滚数据。

TCC (Try Confirm Cancel)

Try 阶段:尝试执行,完成所有业务检查(一致性),预留必需业务资源(准隔离性)。

Confirm 阶段:确认真正执行业务,不作任何业务检查,只使用 Try 阶段预留的业务资源,Confirm 操作满足幂等性。要求具备幂等设计,Confirm 失败后需要进行重试。

Cancel 阶段:取消执行,释放 Try 阶段预留的业务资源,Cancel 操作满足幂等性。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

举个简单的例子:如果你用 100 元买了一瓶水, Try 阶段:你需要向你的钱包检查是否够 100 元并锁住这 100 元,水也是一样的。

如果有一个失败,则进行 Cancel(释放这 100 元和这一瓶水),如果 Cancel 失败不论什么失败都进行重试 Cancel,所以需要保持幂等。

如果都成功,则进行 Confirm,确认这 100 元被扣,和这一瓶水被卖,如果 Confirm 失败无论什么失败则重试(会依靠活动日志进行重试)。

转载请注明:ZMAS‘S blog » 分布式事务

喜欢 (3)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址