分布式事务基础

这一篇主要介绍分布式事务的基础知识,一些基础的算法、定理、简单应用等。下篇文章介绍互联网业界的具体实践方案。

1、CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的,其核心思想是任何基于网络的数据共享,系统最多只能满足数据一致性(Consistency)、可用性(Availability)和网络分区容忍(Partition Tolerance)三个特性中的两个,三个特性的定义如下:

  • 一致性(Consistency) : 等同于所有节点拥有数据的最新版本,对于关系型数据库,要求更新过的数据能被后续的访问都能看到
  • 可用性(Availability) : 数据具备高可用性
  • 分区容错性(Partition tolerance) : 容忍网络出现分区,分区之间网络不可达

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

1.1 CAP的应用实例

在这里插入图片描述

  • CA(一致性+可用性)without P(容错性)
    单机的Mysql和Oracle;
    分布式集群中不存在这种情况,因为多个节点必定考虑主备同步,也就是网络。

  • CP(一致性+容错性)without A(可用性)
    分布式的数据库,如Redis,HBase,Zookeeper
    任何时刻对ZooKeeper请求能得到一致的数据结果:当master节点网络故障,会进行选举机制,选举时集群不可用。但是它不能保证每次服务请求的可用性,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果。

  • AP(可用性+容错性)without C(一致性)
    12306买票
    购买的时候提示你是有票的(但是可能实际已经没票了),但是过了一会系统提示你下单失败,余票不足。其实舍弃的只是强一致性。退而求其次保证了最终一致性。
    Eureka
    各个节点平等;有节点挂掉,会立刻换至其他节点,保证服务可用,只不过查到的信息可能不是最新的。在网络稳定后,当前实例新的注册信息会被同步到其他节点中。
    一旦网络问题发生,节点之间可能会失去联系。为了保证高可用,需要在用户访问时可以马上得到返回,导致全局数据的不一致性。

2、 BASE理论

在分布式系统中,我们往往追求的是可用性,它的重要程序比一致性要高,那么如何实现高可用性呢? 前人已经给我们提出来了另外一个理论,就是BASE理论,它是用来对CAP定理进行进一步扩充的。BASE理论指的是:

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

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

3、 Paxos协议

Paxos协议由Leslie Lamport最早在1990年提出,由于Paxos在云计算领域的广泛应用Leslie Lamport因此获得了2013年度图灵奖。

Paxos协议提出只要系统中2f+1个节点中的f+1个节点可用,那么系统整体就可用并且能保证数据的强一致性,它对于可用性的提升是极大的,仍然假设单节点的可用性是P,那么2f+1个节点中任意组合的f+1以上个节点正常的可用性P(total)=,又假设P=0.99,f=2,P(total)=0.9999901494,可用性将从单节点的2个9提升到了5个9,这意味着系统每年的宕机时间从87.6小时降到0.086小时,这已经可以满足地球上99.99999999%的应用需求。

Leslie写的两篇论文:《The Part-Time Parliament》和《Paxos Made Simple》比较完整的阐述了Paxos的工作流程和证明过程,Paxos协议把每个数据写请求比喻成一次提案(proposal),每个提案都有一个独立的编号,提案会转发到提交者(Proposer)来提交,提案必须经过2f+1个节点中的f+1个节点接受才会生效,2f+1个节点叫做这次提案的投票委员会(Quorum),投票委员会中的节点叫做Acceptor,Paxos协议流程还需要满足两个约束条件: a)Acceptor必须接受它收到的第一个提案;b)如果一个提案的v值被大多数Acceptor接受过,那后续的所有被接受的提案中也必须包含v值(v值可以理解为提案的内容,提案由一个或多个v和提案编号组成)。

Paxos协议流程划分为两个阶段,第一阶段是Proposer学习提案最新状态的准备阶段;第二阶段是根据学习到的状态组成正确提案提交的阶段,完整的协议过程如下:

阶段 1

  1. Proposer选择一个提案编号n ,然后向半数以上的Acceptors发送编号为 n 的prepare请求。

  2. 如果一个Acceptor收到一个编号为n 的prepare请求,且 n 大于它已经响应的所有prepare请求的编号,那么它就会保证不会再通过(accept)任何编号小于 n 的提案,同时将它已经通过的最大编号的提案(如果存在的话)作为响应。

阶段 2

  1. 如果Proposer收到来自半数以上的Acceptor对于它的prepare请求(编号为n )的响应,那么它就会发送一个针对编号为 n ,value值为 v 的提案的accept请求给Acceptors,在这里 v 是收到的响应中编号最大的提案的值,如果响应中不包含提案,那么它就是任意值。

  2. 如果Acceptor收到一个针对编号n 的提案的accept请求,只要它还未对编号大于 n 的prepare请求作出响应,它就可以通过这个提案。

用时序图来描述Paxos协议如图3所示:
Paxos协议流程的时序图
上述Paxos协议流程看起来比较复杂,是因为要保证很多边界条件下的协议完备性,譬如初试值为空、两个Proposer同时提交提案等情况,但Paxos协议的核心可以简单描述为:Proposer先从大多数Acceptor那里学习提案的最新内容,然后根据学习到的编号最大的提案内容组成新的提案提交,如果提案获得大多数Acceptor的投票通过就意味着提案被通过。由于学习提案和通过提案的Acceptor集合都超过了半数,所以一定能学到最新通过的提案值,两次提案通过的Acceptor集合中也一定存在一个公共的Acceptor,在满足约束条件b时这个公共的Acceptor时保证了数据的一致性,于是Paxos协议又被称为多数派协议。

Paxos协议的真正伟大之处在于它的简洁性,Paxos协议流程中任何消息都是可以丢失的,一致性保证并不依赖某个特殊消息传递的成功,这极大的简化了分布式系统的设计,极其匹配分布式环境下网络可能分区的特点,相比较在Paxos协议之前的“两阶段提交(2PC)”也能保证数据强一致性,但复杂度相当高且依赖单个协调者的可用性。

那既然Paxos如此强大,那为什么还会出现ZAB协议?

4、 ZAB 协议

Paxos协议虽然是完备的,但要把它应用到实际的分布式系统中还有些问题要解决:

  • 在多个Proposer的场景下,Paxos不保证先提交的提案先被接受,实际应用中要保证多提案被接受的先后顺序怎么办?

  • Paxos允许多个Proposer提交提案,那有可能出现活锁问题,出现场景是这样的:提案n在第二阶段还没有完成时,新的提案n+1的第一阶段prepare请求到达Acceptor,按协议规定Acceptor将响应新提案的prepare请求并保证不会接受小于n+1的任何请求,这可能导致提案n将不会被通过,同样在n+1提案未完成第二阶段时,假如提案n的提交者又提交了n+2提案,这可能导致n+1提案也无法通过。

  • Paxos协议规定提案的值v只要被大多数Acceptor接受过,后续的所有提案不能修改值v,那现实情况下我还要修改v值怎么办?

ZooKeeper的核心算法ZAB通过一个简单的约束解决了前2个问题:所有提案都转发到唯一的Leader(通过Leader选举算法从Acceptor中选出来的)来提交,由Leader来保证多个提案之间的先后顺序,同时也避免了多Proposer引发的活锁问题。

ZAB协议的过程用时序图描述如图4所示,相比Paxos协议省略了Prepare阶段,因为Leader本身就有提案的最新状态,不需要有提案内容学习的过程,图中的Follower对应Paxos协议中的Acceptor,Observer对应Paxos中的Learner。
ZAB协议的工作过程
ZAB引入Leader后也会带来一个新问题: Leader宕机了怎么办?其解决方案是选举出一个新的Leader,选举Leader的过程也是一个Paxos提案决议过程,这里不展开讨论。

那如何做到提案的值v可以修改呢?这不是ZAB协议的范畴,研究ZooKeeper源码后发现它是这么做的:ZooKeeper提供了一个znode的概念,znode可以被修改,ZooKeeper对每个znode都记录了一个自增且连续的版本号,对znode的任何修改操作(create/set/setAcl)都会促发一次Paxos多数派投票过程,投票通过后znode版本号加1,这相当于用znode不同版本的多次Paxos协议来破除单次Paxos协议无法修改提案值的限制。

从保证一致性的算法核心角度看ZAB确实是借鉴了Paxos的多数派思想,但它提供的全局时序保证以及ZooKeeper提供给用户可修改的znode才让Paxos在开源界大放异彩,所以ZAB的价值不仅仅是提供了Paxos算法的优化实现,也难怪ZAB的作者一直强调ZAB和Paxos是不一样的算法。

CAP理论告诉我们在分布式环境下网络分区无法避免,需要去权衡选择数据的一致性和可用性,Paxos协议提出了一种极其简单的算法在保障数据一致性时最大限度的优化了可用性,ZooKeeper的ZAB协议把Paxos更加简化,并提供全局时序保证,使得Paxos能够广泛应用到工业场景。

5、两阶段提交协议(2PC)

两阶段提交协议(Two-phase Commit Protocol,简称 2PC),是分布式事务的核心协议。在此协议中,一个事务管理器(Transaction Manager,简称 TM)协调 1 个或多个资源管理器(Resource Manager,简称 RM)的活动,所有资源管理器向事务管理器汇报自身活动状态,由事务管理器根据各资源管理器汇报的状态(完成准备或准备失败)来决定各资源管理器是“提交”事务还是进行“回滚”操作。

二阶段提交的具体流程如下:

  1. 应用程序向事务管理器提交请求,发起分布式事务;
  2. 在第一阶段,事务管理器联络所有资源管理器,通知它们准备提交事务;
  3. 各资源管理器返回完成准备(或准备失败)的消息给事务管理器(响应超时算作失败);
  4. 在第二阶段:
    1. 如果所有资源管理器均完成准备(如图 1),则事务管理器会通知所有资源管理器执行事务提交;
    2. 如果任一资源管理器准备失败(如图 2 中的资源管理器 B),则事务管理器会通知所有资源管理器进行事务回滚。

在这里插入图片描述
在这里插入图片描述

6、TCC模型

Try-Confirm-Cancel(TCC)是初步操作(Try)、确认操作(Confirm)和取消操作(Cancel)三种操作的缩写,这三种操作的业务含义如下:

  • Try 阶段:对业务系统做检测及资源预留;
  • Confirm 阶段:对业务系统做确认提交。默认 Confirm 阶段是不会出错的,只要 Try 成功,Confirm 一定成功;
  • Cancel 阶段:当业务执行出现错误,需要回滚的状态下,执行业务取消,释放预留资源。

TCC 是二阶段提交协议(Two-phase Commit Protocol,简称 2PC)的扩展,Try 操作对应 2PC 中一阶段的准备提交事务(Prepare),Confirm 对应 2PC 中二阶段事务提交(Commit),Cancel 对应 2PC 中二阶段事务回滚(Rollback)。

与 2PC 不同的是,TCC 是一种编程模型,是应用层的 2PC;TCC 的 3 个操作均由编码实现,通过编码实现了 2PC 资源管理器的功能。

TCC 自编码的特性决定 TCC 资源管理器可以跨数据库、跨应用实现资源管理,将对不同的数据库访问、不同的业务操作通过编码方式转换一个原子操作,解决了复杂业务场景下的事务问题。同时 TCC 的每一个操作对于数据库来讲都是一个本地数据库事务,操作结束则本地数据库事务结束,数据库的资源也就被释放;这就规避了数据库层面的 2PC 对资源占用导致的性能低下问题。

7、柔性事务

7.1 柔性事务的定义

刚性事务(如单数据库)完全遵循 ACID 规范,即数据库事务正确执行的四个基本要素:

  • 原子性(Atomicity)
  • 一致性(Consistency)
  • 隔离性(Isolation)
  • 持久性(Durability)

柔性事务(如分布式事务)为了满足可用性、性能与降级服务的需要,降低一致性(Consistency)与隔离性(Isolation)的要求,遵循 BASE 理论:

  • 基本业务可用性(Basic Availability)
  • 柔性状态(Soft state)
  • 最终一致性(Eventual consistency)

同样的,柔性事务也部分遵循 ACID 规范:

  • 原子性:严格遵循
  • 一致性:事务完成后的一致性严格遵循;事务中的一致性可适当放宽
  • 隔离性:并行事务间不可影响;事务中间结果可见性允许安全放宽
  • 持久性:严格遵循

7.2 柔性事务的分类

柔性事务分为:两阶段型、补偿型、异步确保型、最大努力通知型。

  • 两阶段型
    分布式事务二阶段提交,对应技术上的 XA、JTA/JTS,这是分布式环境下事务处理的典型模式。

  • 补偿型
    TCC 型事务(Try-Confirm-Cancel)可以归为补偿型。在 Try 成功的情况下,如果事务要回滚,Cancel 将作为一个补偿机制,回滚 Try 操作;TCC 各操作事务本地化,且尽早提交(没有两阶段约束);当全局事务要求回滚时,通过另一个本地事务实现“补偿”行为。
    TCC 是将资源层的二阶段提交协议转换到业务层,成为业务模型中的一部分。

  • 异步确保型
    将一些有同步冲突的事务操作变为异步操作,避免对数据库事务的争用,如消息事务机制。

  • 最大努力通知型
    通过通知服务器(消息通知)进行,允许失败,有补充机制。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/313498.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

支持前端、后台业务代码扩展的快速开发框架

框架采用.NetCore Vue前后端分离,并且支持前端、后台代码业务动态扩展,框架内置了一套有着20多种属性配置的代码生成器,可灵活配置生成的代码,代码生成器界面配置完成即可生成单表/主从表的增、删、改、查、导入、导出、上传、审…

保证分布式系统数据一致性的6种方案

分布式系统数据一致性的基础知识,传送门 1、问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B…

15年来这8门编程语言位置十分稳定,C#从低谷开始爬升

TIOBE 编程语言排行榜 10 月份的榜单已公布,这期的标题比较有趣 —— “Top 8 of the TIOBE index quite stable for the last 15 years”,意思就是排名前 8 的编程语言在这 15 年里一直都十分稳定。有多稳定呢?根据 TIOBE 统计的数据&#x…

Dubbo相关

mark http://ifeve.com/dubbo-learn-book/ http://dubbo.apache.org/zh-cn/ Dubbo架构图 框架分层架构中,各个层次的设计要点: 服务接口层(Service):该层是与实际业务逻辑相关的,根据服务提供方和服务消费…

同时支持EF+Dapper的混合仓储,助你快速搭建数据访问层

背景17年开始,公司开始向DotNet Core转型,面对ORM工具的选型,当时围绕Dapper和EF发生了激烈的讨论。项目团队更加关注快速交付,他们主张使用EF这种能快速开发的ORM工具;而在线业务团队对性能有更高的要求,他…

Dubbo——增强SPI的实现

一、前言 在Duboo剖析-整体架构分析中介绍了dubbo中除了Service 和 Config 层为 API外,其他各层均为SPI,为SPI意味着下面各层都是组件化可以被替换的,这也是dubbo比较好的一点。 二、JDK中标准SPI JDK 中的 SPI(Service Provider…

【 .NET Core 3.0 】框架之二 || 后端项目搭建

前言至于为什么要搭建.Net Core 平台,这个网上的解释以及铺天盖地,想了想,还是感觉重要的一点,跨平台,嗯!没错,而且比.Net 更容易搭建,速度也更快,所有的包均由Nuget提供…

怎样打造一个分布式数据库

本文来自:https://www.infoq.cn/article/how-to-build-a-distributed-database 文章写得很好,备份防丢失 在技术方面,我自己热衷于 Open Source,写了很多 Open Source 的东西,擅长的是 Infrastructure 领域。Infrastru…

向net core 3.0进击——Swagger的改变

前言十一小长假在不知不觉间可都没了,在这个小尾巴的空隙,把这两天鼓捣的net core 3.0升级过程记录一下,首先还是根据之前的顺序一个个补充进来,先从Swagger的变化说起(新建工程什么的不多说了,就是选择的时…

Dubbo——面试问题集(1~3)

1、默认使用的是什么通信框架&#xff0c;还有别的选择吗? Dubbo默认使用netty&#xff0c;还支持mina, grizzy 配置方式&#xff1a; <dubbo:protocol name“dubbo” port“9090” server“netty” client“netty” codec“dubbo” serialization“hessian2” charset…

Dubbo——面试问题集(4~14)

4、默认使用什么序列化框架&#xff0c;你知道的还有哪些&#xff1f; 在Dubbo RPC中&#xff0c;同时支持多种序列化方式&#xff1a; dubbo序列化&#xff0c;阿里尚不成熟的java序列化实现。 hessian2序列化&#xff1a;hessian是一种跨语言的高效二进制的序列化方式&…

向net core 3.0进击——April.WebApi从2.2爬到3.0

前言在之前对Swagger的变化做了调整后&#xff0c;就开始想着要不把之前的工程升级得了&#xff0c;这样就还是个demo工程&#xff0c;来做各种测试&#xff08;当然还是因为懒&#xff09;&#xff0c;这就有了今天这个比较折腾的一步。升级之路首先&#xff0c;April.WebApi工…

共识与拜占庭将军问题

1、共识基础 人们对共识机制的研究其实由来已久&#xff0c;从上世纪70年代就开始了相关研究&#xff0c;其目的是为了解决分布式系统中的一致性问题。Fischer, Lynch 和 Patterson在1985年发表的论文中提出了可以说是最重要的分布式系统定理&#xff1a;FLP不可能定理&#x…

C#刷遍Leetcode面试题系列连载(2): No.38 - 报数

前言前文传送门&#xff1a;上篇文章中我们主要科普了刷 LeetCode 对大家的作用&#xff0c;今天咱们就正式进行 LeetCode 算法题分析。很多人都知道计算机中有种思想叫 递归&#xff0c;相应地也出现了很多算法。解决递归问题的要点有如下几个:找出递归的关系比如&#xff0c;…

Bumblebee微服务网关之负载策略

作为一个微服务网关&#xff0c;提供不同负载策略配置是一项非常重要的主要功能&#xff1b;在这方向Bumblebee提供了非常好的支持。Bumblebee可以针对不同路径制定各自的负载策略&#xff0c;更重要的是这些调整都可以在网关运行过程动态调整&#xff01;动态策略调整可以更好…

FastDFS分布式文件系统设计原理

FastDFS是一个开源的轻量级分布式文件系统&#xff0c;由跟踪服务器&#xff08;tracker server&#xff09;、存储服务器&#xff08;storage server&#xff09;和客户端&#xff08;client&#xff09;三个部分组成&#xff0c;主要解决了海量数据存储问题&#xff0c;特别适…

14年百度深度学习校招题目

一、简答题1.深度神经网络目前有哪些成功的应用&#xff1f;简述原因。(10分) 2.列举不同进程共享数据的方式&#xff08;至少三种&#xff09;。(10分) 3.对于N个样本&#xff0c;每个样本为D维向量&#xff0c;采用欧式距离使用KNN做类预测。(10分) 1).给出预测时间复杂度。 …

HDFS分布式文件系统设计原理

Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统&#xff0c;适合部署在廉价的机器上。它能提供高吞吐量的数据访问&#xff0c;非常适合大规模数据集上的应用。要理解HDFS的内部工作原理&#xff0c;首先要理解什…

Magicodes.IE已支持导出Word、Pdf和Html

关于Magicodes.IE导入导出通用库&#xff0c;通过导入导出DTO模型来控制导入和导出&#xff0c;支持Excel、Word、Pdf和Html。GitHub地址&#xff1a;https://github.com/xin-lai/Magicodes.IE特点需配合相关导入导出的DTO模型使用&#xff0c;支持通过DTO以及相关特性控制导入…

AOP框架Dora.Interception 3.0 [1]: 编程体验

.NET Core正式发布之后&#xff0c;我为.NET Core度身定制的AOP框架Dora.Interception也升级到3.0。这个版本除了升级底层类库&#xff08;.NET Standard 2.1&#xff09;之外&#xff0c;我还对它进行大范围的重构甚至重新设计。这次重构大部分是在做减法&#xff0c;其目的在…