七种分布式事务的解决方案,一次讲给你听

今天看到一篇分布式事务的推文,介绍了7种分布式事务的解决方案,适合简单了解

微信公众号:moon聊技术
七种分布式事务的解决方案,一次讲给你听

什么是分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器「分别位于不同的分布式系统的不同节点之上」。

一个大的操作由N多的小的操作共同完成。而这些小的操作又分布在不同的服务上。针对这些操作,要么全部成功执行,要么全部不执行。

为什么会有分布式事务?

举个例子:
在这里插入图片描述
转账是最经典的分布式事务场景,假设用户 A 使用银行 app 发起一笔跨行转账给用户 B,银行系统首先扣掉用户 A 的钱,然后增加用户 B 账户中的余额。

如果其中某个步骤失败,此时就有可能会出现 2 种「异常」情况:

  • 用户 A 的账户扣款成功,用户 B 账户余额增加失败
  • 用户 A 账户扣款失败,用户 B 账户余额增加成功。

对于银行系统来说,以上 2 种情况都是「不允许发生」,此时就需要事务来保证转账操作的成功。

在「单体应用」中,我们只需要贴上@Transactional注解就可以开启事务来保证整个操作的「原子性」。

但是看似以上简单的操作,在实际的应用架构中,不可能是单体的服务,我们会把这一系列操作交给「N个服务」去完成,也就是拆分成为「分布式微服务架构」。假设订单服务,库存服务分别是不同的服务,不是用同一个数据库。

在这里插入图片描述
比如下订单服务,扣库存服务等等,必须要「保证不同服务状态结果的一致性」,于是就出现了分布式事务。

分布式理论

一、CAP定理

在一个分布式系统中,以下三点特性无法同时满足,「鱼与熊掌不可兼得」

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

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

分区容错性(P):
即使出现「单个组件无法可用,操作依然可以完成」。

具体地讲在分布式系统中,在任何数据库设计中,一个Web应用「至多只能同时支持上面的两个属性」。显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。

二、BASE理论

在分布式系统中,我们往往追求的是可用性,它的重要程序比一致性要高,那么如何实现高可用性呢?

前人已经给我们提出来了另外一个理论,就是BASE理论,它是用来对CAP定理进行进一步扩充的。BASE理论指的是:

  • 「Basically Available(基本可用)」
  • 「Soft state(软状态)」
  • 「Eventually consistent(最终一致性)」

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

分布式事务解决方案

  • 两阶段提交(2PC)
  • 三阶段提交(3PC)
  • 补偿事务(TCC)
  • 本地消息表
  • 消息事务
  • 最大努力通知
  • Sagas 事务模型

具体请看原文

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页