从2PC和容错共识算法讨论zookeeper中的Create请求

这篇具有很好参考价值的文章主要介绍了从2PC和容错共识算法讨论zookeeper中的Create请求。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

大家好,我是方圆。最近在读《数据密集型应用系统设计》,其中谈到了zookeeper对容错共识算法的应用。这让我想到之前参考的zookeeper学习资料中,误将容错共识算法写成了2PC(两阶段提交协议),所以准备以此文对共识算法和2PC做梳理和区分,也希望它能帮助像我一样对这两者有误解的同学。

1. 2PC(两阶段提交协议)

两阶段提交 (two-phase commit) 协议是一种用于实现 跨多个节点的原子事务(分布式事务)提交 的算法。它能确保所有节点提交或所有节点中止,并在某些数据库内部使用,也以 XA事务 的形式在分布式服务中使用。

在 Java EE 中,XA事务使用 JTA(Java Transaction API) 实现。

2PC的实现

2PC包含 准备阶段提交阶段 两个阶段,需要借助 协调者(事务管理器,如阿里巴巴的Seata) 来实现,参与分布式事务的数据库节点为 参与者。当分布式服务中的节点准备提交时,协调者开始 准备阶段:发送一个 准备请求 到每个节点,询问它们是否能够提交,然后协调者会跟踪参与者的响应

  • 如果所有参与者都回答"是",表示它们已经准备好提交,那么协调者在 提交阶段 发出 提交请求,分布式事务提交
  • 如果任意一个参与者回答"否",则协调者在 提交阶段 中向所有节点发送 中止请求,分布式事务回滚

从2PC和容错共识算法讨论zookeeper中的Create请求

上图是2PC提交成功的情况,我们来详述下过程:

  1. 当服务启动一个分布式事务时,它会向协调者请求一个事务ID,此事务ID是全局唯一的
  2. 在每个参与者上启动单节点事务,每个单节点事务会持有这个全局事务 ID。所有的读写都是在这些单节点事务中各自完成的。如果在这个阶段出现任何问题(节点崩溃或请求超时),则协调者或任何参与者都可以中止
  3. 当应用准备提交时,对应准备阶段:协调者向所有参与者发送一个 准备请求,同样也持有全局事务 ID 。如果任意一个请求失败或超时,则协调者向所有参与者发送针对该事务 ID 的 中止请求,即2PC提交中止的情况
  4. 参与者收到 准备请求 时,需要确保在任意情况下都可以提交事务。这包括将所有事务数据写入磁盘(出现故障,电源故障,或硬盘空间不足都不能是稍后拒绝提交的理由)以及检查是否存在任何冲突或违反约束。通过向协调者回答 “是”,节点承诺这个事务一定可以不出差错地提交。也就是说:参与者没有实际提交,同时放弃了中止事务的权利
  5. 当协调者收到所有 准备请求 的答复时,会就 提交或中止事务 作出明确的决定(只有在 所有参与者 投赞成票的情况下才会提交),这里对应提交阶段。协调者必须把这个提交或中止事务的决定 写到磁盘上的事务日志中,记录为 提交点(commit point)。如果它随后崩溃,能通过提交点进行恢复
  6. 一旦协调者的决定已经保存在事务日志中,提交或中止请求会发送给所有参与者。如果这个请求失败或超时,协调者 必须永远保持重试,直到成功为止,对于已经做出的决定,协调者不管需要多少次重试它都必须被执行

2PC协议中有两个关键的 不归路 需要注意:

  • 一旦协调者做出决定,这一决定是不可撤销的
  • 参与者投票 “是” 时,它承诺它稍后肯定能够提交(尽管协调者可能仍然选择放弃),即使参与者在此期间崩溃,事务也需要在其恢复后提交,而且由于参与者投了赞成,它不能在恢复后拒绝提交

这些承诺保证了2PC的 原子性。

协调者失效的情况

如果 协调者失效 并且所有参与者都收到了准备请求并投了是,那么参与者什么都做不了只能等待,而且这种情况 解决方案 是等待协调者恢复或数据库管理员介入操作来提交或回滚事务,当然如果在生产期间这需要承担运维压力。

所以,协调者在向参与者发送提交或中止请求 之前,将其提交或中止决定写入磁盘上的事务日志(提交点)。这样就能在协调者发生崩溃恢复后,通过读取其事务日志来确定所有 存疑事务 的状态,任何在协调者事务日志中没有提交记录的事务都会被终止。因此两阶段提交在第二阶段(提交阶段)存在阻塞等待协调者恢复的情况,所以两阶段提交又被称为 阻塞原子提交协议

番外:3PC

三阶段提交协议也是应用在分布式事务提交中的算法,它的提出是为了解决两阶段提交协议中存在的阻塞问题。它分为 CanCommit阶段PreCommit阶段DoCommit阶段,通过引入 参与者超时判断机制 来解决2PC中存在的参与者依赖协调者的提交请求而阻塞导致的资源占用等问题。

从2PC和容错共识算法讨论zookeeper中的Create请求

上图为在DoCommit阶段,参与者判断 DoCommit请求 超时情况的流程图,我们详述下它的避免阻塞的流程

  1. 服务在每个参与者上启动单节点事务,当参与者准备提交时,对应CanCommit阶段,协调者会向所有参与者发送 CanCommit请求,如果任意一个请求失败或超时,则协调者会向所有参与者发送针对该事务的 中止请求,执行事务回滚
  2. 当协调者收到所有CanCommit请求的答复时,如果全是“是”那么则进入PreCommit阶段,否则发送中止请求,执行事务回滚
  3. 进入PreCommit阶段后,协调者会向所有参与者发送 PreCommit请求,同样还是如果存在请求失败或超时,会发送中止请求执行事务回滚
  4. 协调者收到所有PreCommit请求的答复时,如果全是“是”那么则进入DoCommit阶段,否则发送中止请求,执行事务回滚
  5. 进入DoCommit阶段后,协调者会向所有参与者发送 DoCommit请求,注意这里,如果某个参与者没有收到该请求,它默认认为协调者会发送提交请求,那么便本地执行提交事务,从而避免阻塞

3PC虽然解决了2PC中存在的阻塞问题,但是也引入了新的问题:

  • 如果协调者在DoCommit阶段回复的是中止请求,那么超时节点自顾自地提交事务就会发生数据不一致的情况
  • 通讯次数增加和实现相对复杂

3PC使原子提交协议变成非阻塞的,但是3PC 假定网络延迟和节点响应时间有限,在大多数具有无限网络延迟和进程暂停的实际系统中,它 并不能保证原子性。非阻塞原子提交需要一个 完美的故障检测器 来以可靠的机制判断一个节点是否已经崩溃,而在无限延迟的网络中,超时并不是一种可靠的故障检测机制,因为即使节点没有崩溃也会因为网络延迟而超时,出于这个原因,2PC仍然被使用,尽管存在协调者故障的问题。

2. 容错共识算法

容错共识算法用于 节点间数据同步,保证各个副本间数据的一致性和集群的高可用。它的通常形式是一个或多个节点可以 提议(propose) 某些值,而共识算法 决定(decides) 采用其中的某个值,并让这些节点就提议达成一致。共识算法必须具备如下性质:

  • 一致同意:没有两个节点的决定不同
  • 完整性:没有节点决定两次
  • 有效性:如果节点决定了v值,那么v由该节点所提议
  • 终止性:由所有未崩溃的节点来最终决定值

终止性实质上是说:容错共识算法不能简单地永远闲坐着等待,而是需要根据大多数节点来达成一项决定,因此终止属性也暗含着 不超过一半的节点崩溃或不可达 的信息。

一致同意和完整性是共识的 核心思想,即所有节点决定了相同的结果并且决定后不能改变主意。

容错共识算法在节点集群内部都以某种形式使用一个领导者,并定义了一个 纪元编号(epoch number) 来确保在每个时代中,领导者都是唯一的。每当现任领导宕机时,节点间会开始一场投票,来选出一个新的领导,每次选举被赋予一个新的纪元编号(全序且单调递增),如果有两个不同时代的领导者之间出现冲突(脑裂问题),那么带有更高纪元编号的领导者说了算。领导者每想要做出的每一个决定,都必须将提议值发送给其他节点,并等待 法定人数 的节点响应并赞成提案。法定人数通常(但不总是)由多数节点组成(一般为过半),只有在没有发现任何带有更高纪元编号的领导者的情况下,一个节点才会投票赞成提议。

容错共识算法的局限性
  1. 节点在做出决定之前对提议进行投票的过程是一种同步复制
  2. 共识系统总是需要有 法定人数 的节点存活来保证运转
  3. 大多数共识算法假定参与投票的节点是固定的集合,这意味着你不能简单的在集群中添加或删除节点
  4. 共识系统通常依靠 超时 来检测失效的节点,在网络延迟高度变化的环境中,特别是在地理上散布的系统,经常发生一个节点由于暂时的网络问题,错误地认为领导者已经失效。虽然这种错误不会损害安全属性,但频繁的领导者选举会导致糟糕的性能表现,所以共识算法对网络问题比较敏感,而在面对不可靠的网络相关的共识算法研究仍在进展中

3. 2PC和容错共识算法的区别

  1. 负责解决的问题不同:2PC解决的是分布式事务的一致性,各个节点存储的数据各有不同,目标侧重于保证事务的ACID;容错共识算法解决的是节点副本间数据的一致性和保证集群的高可用,节点间存储的数据完全一致,目标侧重于数据的复制和同步
  2. 每个提议通过要求的参与节点数不同:2PC要求 所有的参与者表决成功 才通过;容错共识算法只需要 遵循基于法定人数的表决 即可,这也是容错共识算法 终止属性(由所有未崩溃的节点来决定最终值) 的体现
  3. 集群的高可用保证:2PC的协调者不是通过选举产生的,而是单独部署并人为指定的组件,所以它没有选主机制,不具备高可用性;应用容错共识算法的集群领导者是通过选举机制来指定的,并且在发生异常情况时(主节点宕机)能够选出新的领导者,并进入一致的状态,以此来保证集群的高可用

4. zookeeper中的一次Create请求

一些资料中会提到zookeeper在执行CRUD请求时,使用的是2PC,而 实际上它使用的是容错共识算法。我们以Create请求的流程为例(如下图),来加深和记忆这一知识

从2PC和容错共识算法讨论zookeeper中的Create请求文章来源地址https://www.toymoban.com/news/detail-487962.html

  1. 客户端发 create 请求到 Leader,即使请求没落到 Leader 上,那么其他节点也会将写请求转发到 Leader
  2. Leader 会先发一个 提议(proposal)请求给各个 Follower,且自己将数据写到本地文件
  3. Follower 集群收到 proposal 请求后会将数据写到本地文件,写成功后返回给 Leader 一个 ack回复
  4. Leader 发现收到 ack 回复的数量为 法定人数(过半,包含当前 Leader 节点)时,则提交一个 commit 请求给各个 Follower 节点。发送 commit 请求就代表该数据在集群内同步情况没有问题,并且 可以对外提供访问 了,此时Leader会把数据写到内存中
  5. Follower 收到 commit 请求后也会将数据写到各自节点的内存中,同时Leader会将数据发给 Observer集群,通知 Observer集群 将数据写到内存

巨人的肩膀

  • 《数据密集型应用系统设计》第九章:分布式事务与共识
  • 百度百科:三阶段提交
  • 浅谈分布式一致性协议之3PC
  • 分布式事务(2PC) vs 共识协议(Paxos/raft)
  • 《深度剖析zookeeper核心原理》
  • 原文收录:GitHub-Enthusiasm

到了这里,关于从2PC和容错共识算法讨论zookeeper中的Create请求的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 无共识不区块链,一起了解拜占庭容错共识机制(BFT)

    引言 区块链技术的核心组成部分之一是共识机制。共识机制确保在分布式网络中各个节点之间达成一致,以防止双重支付和恶意行为。在讨论共识机制时,拜占庭将军问题是一个经典的思想实验,它启发了对分布式系统中共识难题的探讨。本文将通过详细解释区块链的共识机

    2024年04月15日
    浏览(61)
  • 分布式「走进分布式一致性协议」从2PC、3PC、Paxos 到 ZAB

    设计一个分布式系统必定会遇到一个问题—— 因为分区容忍性(partition tolerance)的存在,就必定要求我们需要在系统可用性(availability)和数据一致性(consistency)中做出权衡 。这就是著名的 CAP 一致性(Consistency)是指多副本(Replications)问题中的数据一致性。关于分布式

    2024年02月03日
    浏览(66)
  • 区块链中的共识机制以及共识算法

    目录 什么是共识 什么是共识机制 共识机制类型 1、基于工作证明(Proof of Work PoW) PoW的特点

    2024年02月11日
    浏览(46)
  • 区块链技术中的共识机制算法:以权益证明(PoS)为例_区块链 pos

    先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7 深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前! 因此收集整理了一份《2024年最新网络安全全套学习资料》

    2024年04月23日
    浏览(44)
  • 使用ZooKeeper实现数据分片机制及其集群容错能力

    作者:禅与计算机程序设计艺术 在分布式数据库中,数据分片是指将一个大的表按照业务规则或某种规则拆分成多个小的子表或者分区,然后分别存储到不同的物理服务器上,提高查询效率、扩展性等,而每个小的子表又可以称之为“分片”,这个过程就是数据分片。一般情

    2024年02月05日
    浏览(47)
  • 解决Zookeeper高可用性挑战:使用副本集和容错策略

    作者:禅与计算机程序设计艺术 《10. 解决Zookeeper高可用性挑战:使用副本集和容错策略》 引言 1.1. 背景介绍 Zookeeper是一个开源的分布式协调系统,可以提供可靠的协调服务,支持分布式事务、发布/订阅模式等功能。Zookeeper的高可用性对于分布式系统的稳定运行至关重要。

    2024年02月15日
    浏览(49)
  • Dubbo3使用Zookeeper作为注册中心的方案讨论!详解DubboAdmin与PrettyZoo来监控服务的优劣!

    文章目录 一:Dubbo注册中心的基本使用 二:Zookeeper注册中心的使用 1:依赖引入 2:实际开发 三:Zookeeper作为注册中心的使用展示 1:启动注册Zookeeper服务 2:引入注册中心 (一):Provider (二):Consumer 3:启动服务结果展示 4:监控服务的两种手段         我们使用的和分析讲解

    2024年02月05日
    浏览(39)
  • 共识协议(2)共识算法分类

    1. 分类 1.1 概率性共识(弱一致性) 区块数据以一定概率达成一致, 随着时间推移概率逐渐提高, 不能保证区块数据将来不可更改, eg, 比特币 持久性(persistence) 衡量区块链数据的一致性. 如果某区块在节点的本地区块链中拥有k个区块的深度, 该区块在其他节点的本地区块链中

    2023年04月08日
    浏览(35)
  • Flink中的容错机制

    在Flink中,有一套完整的容错机制来保证故障后的恢复,其中最重要的就是检查点。 在流处理中,我们可以用存档读档的思路,将之前某个时间点的所有状态保存下来,这份存档就被称为“检查点(CkeckPoint)”。 当Flink程序异常重启时,我们就可以在检查点中“ 读档 ”,恢

    2024年01月23日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包