深入浅出 -- 系统架构之分布式常见理论概念

随着计算机科学和互联网的发展,分布式场景变得越来越常见,能否处理好分布式场景下的问题,成为衡量一个工程师是否合格的标准。本文我们介绍下分布式系统相关的理论知识,这些理论是我们理解和处理分布式问题的基础。

CAP理论

CAP理论是在1998年由计算机科学家Eric Brewer提出的。介绍下CAP理论。

  • Consintency:一致性,即访问所有节点得到的结果是一致的,这里的一致性指强一致。
  • Availability:可用性,即所有节点保持高可用,这里的高可用还包括不能出现过高的延迟。
  • Partition tolerance:分区容错性,节点之前网络不可用时,系统仍然可以对外提供服务。 CAP理论的原理是:一个系统最多可以同时满足以上三个条件中的两个,不可能三个同时满足。
    之前看到过一个更容易理解的解释方法:
  • C代表一致
  • A代表同一时间
  • P代表不同空间 CP:不同空间,如果数据一致必然不会在同一时间
    AP:不同空间,如果在同一时刻可以从任意空间取数据必然会导致数据状态不一致
    CA:任意时刻获取数据都保证一致,必然P只能是1

结合现实中的业务场景,P(分区容错性)是每一个系统必须满足的要求,我们实际的选择就只有CP和AP两种模型了。 CP模型的特点是,一致性要求高,像我们熟悉的Zookeeper就是典型的CP模型。 AP模型的特点是,保证高可用,数据保持最终一致性,不追求实时的一致性。比较典型的有Eurka

Base理论

Base的全称:Basically Available(基本可用)、Soft state(软状态)和Eventual consistency(最终一致性)。

  • Basically Available:指核心服务/部分服务可用,或响应延时变长。
  • Soft state:指数据同步完部分节点还没有全部同步完成的状态。
  • Eventual consistency:经过系统内部协调,经过有限时间,系统内各节点最终达成一致状态。 Eventual consistency在实践中往往还需要注意几点:
  • 会话一致性,在单次会话中如果数据已经更新,不能再读到旧数据
  • 节点有效性,一个节点上的数据如果已经更新,不能再读到旧数据 Base理论更适合大型分布式系统的整体设计,不同于ACID的强一致模型。它允许通过牺牲强一致来增强系统的可用性,允许经过一定时间数据达到最终一致。在实际业务场景中可以把Base和ACID结合使用。

2PC

引用维基百科的定义:“二阶段提交(英语:Two-phase Commit)是指在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常,二阶段提交也被称为是一种协议(Protocol)”
二阶段提交,存在协调者执行者两种角色。

第一阶段:提交请求阶段
  1. 协调者向所有执行者发送请求,询问任务是否可执行。
  2. 执行者执行事务的操作,并记录“日志”,但是不进行commit。
  3. 执行者执行完事务之后,返回给协调者执行状态。如果事务执行成功,返回准备完毕状态;如果事务执行失败,返回终止状态。

如果有一个或多个执行者返回终止,发起回滚流程:

  1. 协调者向所有执行者发起回滚请求。
  2. 执行者收到回滚请求,根据第一阶段第二步记录的日志,执行回滚操作。
  3. 执行者回滚完成后,给协调者返回回滚完成
  4. 协调者收到所有执行者返回回滚完成,事务回滚成功。

如果协调者接收到所有执行者返回准备完毕,执行第二阶段。
第二阶段:提交执行阶段

  1. 协调者向所有执行者发起“正式提交”的请求。
  2. 执行者执行commit操作,并释放相关锁资源。
  3. 执行者向协调者发送commit成功消息。
  4. 协调者接收到所有执行者的commit成功消息后,完成事务。 协调者在第二阶段,必须完成任务。

二阶段提交的优缺点:

  • 优点:原理简单,实现简单。
  • 缺点:协调者存在单点问题;所有执行者互相等待,导致阻塞;第一阶段执行者出现故障,协调者就无法判断执行者是否成功执行,只能依赖自身的超时机制来保障回滚;第二阶段,如果执行者发生故障,无法完成commit操作,会导致数据不一致。

3PC

三阶段提交:三阶段提交就是把二阶段提交的第一阶段拆分成了两个阶段,带来的好处是,提前预知风险,减少执行者互相阻塞。

第一阶段:CanCommmit
  1. 协调者向所有执行者发送CanCommit的请求。
  2. 执行者根据自身状况预判是否可以执行Commit,返回“Can”或者“No”。如果有执行者返回“No”或者有执行者请求超时,协调者向所有执行者发送回滚操作,执行者接收到回滚操作(此时的回滚,是比较轻量的)ACK。 如果所有执行者都返回“Can”,则进入下一阶段。
第二阶段:PreCommit
  1. 协调者向所有执行者发送PreCommit请求。
  2. 执行者执行事务,并记录“日志”,但是不做commit,事务执行完返回“Pre”或者“No”。 如果有执行者返回“No”或者有执行者请求超时,协调者向所有执行者发送回滚操作,执行者接收到回滚操作,执行完回滚,ACK。 如果所有执行者都返回“Can”进入下一阶段。
第三阶段:DoCommit
  1. 协调者向所有执行者发送DoCommit请求。
  2. 执行者执行Commit事务,并释放锁,事务执行完返回“完成”或者“失败”
  3. 如果所有执行者都返回“完成”,协调者完成事务。如果有的执行者返回“失败”或者超时,协调者向所有执行者发送“回滚”操作,执行者执行“回滚”,回滚完毕ACK。 优点:三阶段提交缓解了二阶段提交执行者的阻塞问题。但是并没有从根本上解决协调者的单点、网络延迟等问题。

Paxos算法:

“Paxos算法是莱斯利·兰伯特(英语:Leslie Lamport)于1990年提出的一种基于消息传递且具有高度容错特性的共识(consensus)算法”。 Paxos算法有两部分:Basic Paxos和Multi-Paxos。 Basic Paxos是解决多节点如何就某一个值达成共识;Multi-Paxos是多组Basic Paxos如何把一些列值达成共识。Multi-Paxos没有严格的证明过程,更多的是作为解决分布式问题的指导思想。我们这里主要介绍下Basic Paxos算法。 Basic Paxos中有三种角色: Proposer(提议者)、Acceptor(接受者)、Learner(学习者)。

  • Proposer:提出“提议”
  • Acceptor:对“提议”进行投票
  • Learner:记录被批准的“提议” 在算法具体实现时,通常Proposer是第一个接收到客户端请求的节点,节点既是Proposer又是Acceptor。这样可以把算法逻辑尽量集中在服务内部,与客户端解耦。 证明过程可参照维基百科:传送门
最终算法:

通过一个决议分为两个阶段:

阶段一:Prepare阶段

  1. Proposer选择一个提案编号M,向超过半数的Acceptor发送编号为M的Prepare请求。
  2. 如果一个Acceptor收到编号为M的Prepare请求,并且M大于Acceptor已经响应过的所有提案编号。Acceptor给Proposer返回自己已经批准过的最大编号的提案,同时自己承诺不再批准编号小于M的提案。

阶段二:Accept阶段

  1. 如果超过半数的Acceptor给Proposer返回了Prepare响应,Proposer就会发送一个编号为M、值为N的Accept请求给Acceptor
  2. 如果Prepare接收到此请求,并且未对编号大于M的Prepare请求响应,Acceptor就通过这个提案。

我们举一个实际的例子:

P1 P2代表两个Proposer A1 A2 A3代表三个Acceptor

阶段一:Prepare阶段

P1向A1、A2、A3发送编号为1的提案;P2向A1、A2、A3发送编号为2的提案。

  1. A1、A2收到编号为1的提案,因为之前没有接收过提案,所以A1和A2给P1返回响应,并郑重承诺“不再响应编号小于等于1的Prepare请求;不会通过编号小于1的提案”
  2. A1、A2收到P2发来的编号为2的提案,因为2>1,所以A1和A2给P2返回响应,并郑重承诺“不再响应编号小于等于2的Prepare请求;不会通过编号小于2的提案”
  3. A3收到P2发来的编号为2的提案,因为A3之前没有收到过提案,所以给P2返回响应,并郑重承诺“不再响应编号小于等于2的Prepare请求;不会通过编号小于2的提案”
  4. A3收到P1发来的编号为1的提案,因为上一步A3作出的承诺而且提案编号1<2,所以A3对次请求不做响应。

阶段二:Accept阶段

因为P1和P2在Prepare阶段都收到了超过半数Acceptor的响应,所以二者都会发起Accept请求。
P1发起编号为1,值为1的请求;P2发起编号为2,值为2的请求。

  • A1、A2、A3收到P1的Accept请求,应为编号1<2,所以编号为1的提案被拒绝。
  • A1、A2、A3收到P2的Accept请求,应为编号2=2,所以编号为2的都返回响应,通过。

提案获取: Acceptor把批准的提案,发送给Learner的一个leader组,该小组负责把提案信息扩散到所有Learner节点。
Paxos的业界典型实现:Chubby

Raft算法

Raft算法在近几年几乎成了共识性算法的首选。像Etcd、Consul、Tidb都使用了Raft算法。 Raft算法中的节点,存在三种状态Follower(跟随者)和Candidate(候选人)、 Leader(领导者) 3 种状态。

集群诞生:
集群刚刚启动的时候,所有的节点都是Follower,Follower没有收到来自Leader的心跳检测,他会自己提升自己为Candidate,Candidate向别的节点请求选票,如果Candidate接收到大于半数节点的选票,Candidate就会变为Leader。

第一次集群状态一致:
系统的所有改变都要通过Leader节点进行,每一次变更操作都被记录到日志中。
客户端的请求需要先发送到Leader节点
Leader节点第一次把日志发送给Follower节点
Leader节点等待超过半数的节点,已经成功记录了日志(并未提交)
Leader节点commit当前值
Leader通知Follower节点值已经被commit,Follower节点也提交日志。
现在集群达到了第一次启动后的一致状态。

选主:

在Raft算法中有两个超时设置,来控制选主。

  1. 主节点判定超时:Follower在一段时间之后如果没有收到Leader节点的存活检测,就会把自己提升为Candidate。我们假设Follower把这个超时时间设置为150-300ms之间的随机值(150-300ms只是一个示例)。
  2. 主节点被判定超时后,Follower把自己提升为Candidate开始新的一轮选举。
  3. Candidate先投票给自己
  4. Candidate发送投票请求到其他节点
  5. 接收到Candidate请求的节点,如果在这一轮选举中还没有进行过投票,就给当前发来请求的Candidate节点投票。
  6. Candidate节点会在一定范围内随机设置选举的超时时间
  7. 一旦Candidate接收到超过半数的支持者,就会把自己提升为Leader。
  8. Leader发送“Append Entries messages”给他的Follower。而且信息会以心跳检测的形式,周期性的发送,Follower收到“Append Entries messages”给Leader返回响应。心跳检测会一直存在,直到Follower等待心跳检测超时,把自己提升为Candidate。
  9. Candidate要获得超过半数Follower的选票保证一次选举中只能有一位Leader,如果没有的话选举失败。这时,Candidate会随机等待一段时间重新发起下一轮投票,直到选出一位Leader。
日志复制:

一旦我们集群中有了Leader,就需要复制所有的变更到集群中的所有节点,通过发送“Append Entries message”消息来完成日志复制。

  1. 客户端发送信息给Leader,Leader节点把请求信息记录日志。
  2. 在下一次心跳检测时,把日志发送给Follower。
  3. Follower接收到请求给Leader返回响应,一旦超过半数的节点返回响应,Leader节点就commit日志信息。
  4. 给客户端返回响应,同时通知Follower节点commit日志。
节点变更:

在多个节点同时做成员变更期间,如果刚好发生网络分区,容易出现一个集群中多个Leader的现象,这时如果客户端还往集群发送请求,就会出现脑裂。 我们通常使用单节点变更的方式来解决Raft集群的成员变更,即每次只增删一个节点。 单节点成员的变更分为两步:

  1. Leader向新节点同步数据。
  2. Leader将新配置作为日志项发送到集群中的所有节点上。

Raft算法中还有一些规则需要注意:

  1. 任期编号在整个集群中单调递增,一个Candidate或者Leader如果发现了比自己任期编号大的Leader节点,会自动变为Follower。
  2. 如果一个节点收到小于当前任期编号的请求会直接拒绝。
  3. 只要Leader节点在随机时间内一直发送心跳检测请求,Leader节点就一直是Leader。
  4. 日志完整性高(最后记录的日志,任期编号大或者任期编号相同索引项大)的节点拒绝投票给日志完整性比自己低的Candidate。
  5. 在一次选举过程中,一个节点只能有一次投票,最先接受到的请求,最先获得选票。

XA事务

要想理解XA事务,首先需要知道DTP 模型( Distributed Transaction Processing),DTP模型有三个模块:

  • AP:应用程序(Aplication Program),指事务的发起者通常是我们的应用程序。
  • RM:资源管理器(Resource Manager),管理具体资源,而且还要具备事务提交或回滚的能力。通常是存储或者一些公共服务,比如数据库。
  • TM:事务管理器(Transaction Manager),TM 是分布式事务的协调者。TM 可以和所有的RM通信。

XA规范主要规定了RM和TM之间的交互流程,依赖二阶段提交的思路。 XA规定了一些列的接口,如下图:

其中最主要的接口有:

  • xa_open: 初始化RM
  • xa_start: 启动XA事务
  • xa_end: 结束XA事务
  • xa_prepare: 准备阶段,XA事务预提交
  • xa_commit:提交XA事务
  • xa_rollback: 回滚XA事务 XA事务的执行流程我们也以图例的形式展示:

具体步骤:

  1. AP发起事务开始请求
  2. RM给TM发起请求,并调用xa_start方法标记事务开始
  3. AP访问TM执行具体操作,比如数据库的具体操作语句
  4. TM执行xa_end方法,标记事务结束
  5. TM发起xa_prepare,通知RM进行请求提交前的准备工作,类比二阶段提交的请求提交阶段
  6. TM发起xa_commit,通知RM进行提交执行,类比二阶段提交的提交执行阶段。当然如果上一阶段准备失败的话,此阶段执行xa_rollback通知RM回滚事务
  7. TM调用x_close结束事务 因为像MySQL、Oracle等数据库都实现了XA事务,因此我们在做一些跨库操作的时候,不管是不是同一种数据库,只要实现了XA协议,我们都可以调用对方的API完成分布式事务。

TCC

TCC是典型的柔性分布式事务的理论,通过补偿机制,保证数据的最终一致性。TCC的三个阶段:

  1. Try阶段:预执行操作,对业务系统做检测及资源预留。
  2. Confirm阶段:确认执行具体操作。
  3. Cancel阶段:取消执行业务操作。 TCC理解起来比较简单,但是再具体实现时,需要着重考虑一下几个问题:请求接口的幂等设计,try过程中加锁资源的设计等等。

Quorum NWR:

NWR 模型的思想是把 CAP 的选择权交给了用户,让用户通过配置可以灵活调节CAP模型中C和A的选择比重。

  • N:代表总的副本数
  • W:代表写入成功W份(W个副本),才认为写入成功。
  • R:代表至少读取R个备份,才认为读成功。(如果出现数据不一致,往往是挑选最新的数据)

如果 W + R > N,所以 R > N – W,也就是说,每次读取,都至少读取到一个最新的版本。
当需要高可写时,可以配置 W = 1 R = N。只要写任何节点成功就认为成功,但读的时候必须从所有的节点都读出数据 —> 弱一致性,高可用性。
当需要高可读时,可以配置 W = N R = 1。必须写所有节点成功才认为成功,这时读任何一个节点成功就认为成功 —> 强一致性,低可用性

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

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

相关文章

深入理解选择排序:算法原理、Java实现与性能优劣

算法学习的重要性 在程序员的世界里&#xff0c;算法就如同一座桥梁&#xff0c;连接着问题与解决方案&#xff0c;是实现优秀程序的关键。 掌握算法&#xff0c;就能够在面对各种问题时&#xff0c;找到最合适的解决方法&#xff0c;以最少的时间和空间&#xff0c;实现最优的…

Android数据存储技术

一、文件存储 <LinearLayout xmlns:android"http://schemas.android.com/apk/res/android"android:orientation"vertical"android:layout_width"match_parent"android:layout_height"match_parent" ><EditTextandroid:id&qu…

mac 切换 jdk

查看 mac 上都有哪些版本 /usr/libexec/java_home -V看准版本切换 按前缀切换 比如 export JAVA_HOME/usr/libexec/java_home -v 1.8这样会随机一个 1.8 的 如果想再确定一个比如 openjdk export JAVA_HOME/usr/libexec/java_home -v 1.8.0_292这个方式是临时的&#xff0c…

【力扣刷题日记】1421.净现值查询

前言 练习sql语句&#xff0c;所有题目来自于力扣&#xff08;https://leetcode.cn/problemset/database/&#xff09;的免费数据库练习题。 今日题目&#xff1a; 1421.净现值查询 表&#xff1a;NPV 列名类型idintyearintnpvint (id, year) 是该表主键(具有唯一值的列的…

用友NC Cloud importhttpscer 任意文件上传漏洞复现

0x01 产品简介 用友 NC Cloud 是一种商业级的企业资源规划云平台,为企业提供全面的管理解决方案,包括财务管理、采购管理、销售管理、人力资源管理等功能,基于云原生架构,深度应用新一代数字技术,打造开放、 互联、融合、智能的一体化云平台,支持公有云、混合云、专属云…

AI绘画:实例-利用Stable Diffusion ComfyUI实现多图连接:区域化提示词与条件设置

在Stable Diffusion ComfyUI中&#xff0c;有一种高级技巧可以让用户通过细致的区域化提示词来控制图像的不同部分&#xff0c;从而实现多图连接的效果。这种方法允许艺术家在同一画布上展现多个场景&#xff0c;创造出富有层次和故事性的图像。以下是实现这一效果的详细步骤。…

Leetcode链表刷题总结(Java版)

链表 1、移除链表元素&#xff08;考虑全情况&#xff09; 问题需求&#xff1a;根据给定的val值&#xff0c;移除链表中值是这个val的节点 203. 移除链表元素 - 力扣&#xff08;LeetCode&#xff09; 这里有一个问题就是&#xff0c;如果需要被移除的节点不是中间的某个节点…

Tuxera2023 NTFS for Mac下载,安装和序列号激活

对于必须在Windows电脑和Mac电脑之间来回切换的Mac朋友来说&#xff0c;跨平台不兼容一直是一个巨大的障碍&#xff0c;尤其是当我们需要使用NTFS格式的硬盘在Windows和macOS之间共享文件时。因为Mac默认不支持写入NTFS磁盘。 为了解决这一问题&#xff0c;很多朋友会选择很便捷…

【Java基础知识总结 | 第十篇】HashSet底层实现原理

文章目录 10.HashSet底层实现原理10.1HashSet特点10.2HashSet源码10.3 add流程10.4总结 10.HashSet底层实现原理 10.1HashSet特点 存储对象&#xff1a;HashSet 存储对象采用哈希表的方式&#xff0c;它不允许重复元素&#xff0c;即集合中不会包含相同的元素。当向 HashSet …

数据挖掘中的PCA和KMeans:Airbnb房源案例研究

目录 一、PCA简介 二、数据集概览 三、数据预处理步骤 四、PCA申请 五、KMeans 聚类 六、PCA成分分析 七、逆变换 八、质心分析 九、结论 十、深入探究 10.1 第 1 步&#xff1a;确定 PCA 组件的最佳数量 10.2 第 2 步&#xff1a;使用 9 个组件重做 PCA 10.3 解释 PCA 加载和特…

【微服务】------核心组件架构选型

1.微服务简介 微服务架构&#xff08;Microservice Architecture&#xff09;是一种架构概念&#xff0c;旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦&#xff0c;从而降低系统的耦合性&#xff0c;并提供更加灵活的服务支持。 2.微服务技术选型 区域内容…

Kotlin学习日志(一)TextView、Button、Toast的使用(1)

android:layout_width“wrap_content” android:layout_height“wrap_content”/> import kotlinx.android.synthetic.main.activity_main.* 这句话的意思是引进Kotlin的的控件变量自动映射功能&#xff0c;接下来只要是这个activity_main.xml文件中的控件&#xff0c;我…

蓝桥杯第十四届C++A组(未完)

【规律题】平方差 题目描述 给定 L, R&#xff0c;问 L ≤ x ≤ R 中有多少个数 x 满足存在整数 y,z 使得 。 输入格式 输入一行包含两个整数 L, R&#xff0c;用一个空格分隔。 输出格式 输出一行包含一个整数满足题目给定条件的 x 的数量。 样例输入 1 5 样例输出 …

OpenTofu路在何方:定量分析Terraform issue数据,洞察用户需求|OpenTofu Day 闪电演讲

数澈软件 Seal 首席架构师李平辉提交的演讲议题“Alias TerraformTofu. Job’s Done, Now What?”入选 KubeCon EU 同场活动 OpenTofu Day&#xff0c;本文为演讲实录。 大家好&#xff0c;我是 Lawrence&#xff0c;是 Seal 的首席架构师。今天将由我为大家带来 Lightening T…

后端开发框架Spring Boot快速入门

写在前面 推荐将本文与Spring Boot 相关知识和工具类一文结合起来看&#xff0c;本文为主&#xff0c;上面那篇文章为辅&#xff0c;一起食用&#xff0c;以达到最佳效果&#xff0c;当然&#xff0c;大佬随意。 IDEA创建Spring Boot工程 关于Spring Boot框架项目&#xff0…

第二节课《轻松玩转书生·浦语大模型趣味 Demo》

比较匆忙&#xff0c;假期前仿照第一期课程的内容好像被清空了&#xff0c;重新搭建一次。 https://github.com/InternLM/Tutorial/blob/camp2/helloworld/hello_world.md 按照那老师写好的&#xff0c;一步步复制就好了 浦语灵笔2的大概率是会超出显存&#xff0c;先不测试了…

MySQL-排序与分页

1. 排序 如果没有使用排序操作&#xff0c;默认情况下查询返回的数据是按照添加数据的顺序显示的。 SELECT * FROM employees;1.1 基本使用 1&#xff09;使用 ORDER BY 对查询到的数据进行排序操作。 升序&#xff1a;ASC(ascend)降序&#xff1a;DESC (descend) 练习&am…

2024.4.4-[作业记录]-day09-CSS 布局模型(标准流模型、浮动模型)

个人主页&#xff1a;学习前端的小z 个人专栏&#xff1a;HTML5和CSS3悦读 本专栏旨在分享记录每日学习的前端知识和学习笔记的归纳总结&#xff0c;欢迎大家在评论区交流讨论&#xff01; 文章目录 作业 2024.4.4-学习笔记1 CSS 布局模型1.1 标准流1.2 CSS 浮动1.3 去除塌陷 2…

【零基础学数据结构】顺序表实现书籍存储

目录 书籍存储的实现规划 ​编辑 前置准备&#xff1a; 书籍结构体&#xff1a; 书籍展示的初始化和文件加载 书籍展示的销毁和文件保存 书籍展示的容量检查 书籍展示的尾插实现 书籍展示的书籍增加 书籍展示的书籍打印 书籍删除展示数据 书籍展示修改数据 在指定位置之前…

SpamSieve mac垃圾邮件过滤器 直装激活版

SpamSieve通过强大的垃圾邮件过滤技术&#xff0c;帮助用户有效管理和消除不想要的电子邮件。它能与多种电子邮件客户端无缝集成&#xff0c;如Apple Mail、Microsoft Outlook、Airmail等。 软件下载&#xff1a;SpamSieve mac直装激活版下载 该软件利用先进的算法和机器学习技…