我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:2019年全年资料内部公开36码 > 强一致性 >

分布式一致性协议

归档日期:07-24       文本归类:强一致性      文章编辑:爱尚语录

  一致性(Consistency)是指多副本(Replications)问题中的数据一致性。关于分布式系统的一致性模型有以下几种:

  当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值,直到这个数据被其他数据更新为止。

  但是这种实现对性能影响较大,因为这意味着,只要上次的操作没有处理完,就不能让用户读取数据。

  系统并不保证进程或者线程的访问都会返回最新更新过的值。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。甚至不能保证可以访问到。

  最终一致性也是弱一致性的一种,它无法保证数据更新后,所有后续的访问都能看到最新数值,而是需要一个时间,在这个时间之后可以保证这一点(就是在一段时间后,节点间的数据会最终达到一致状态),而在这个时间内,数据也许是不一致的,这个系统无法保证强一致性的时间片段被称为「不一致窗口」。不一致窗口的时间长短取决于很多因素,比如备份数据的个数、网络传输延迟速度、系统负载等。

  如果 A 进程在更新之后向 B 进程通知更新的完成,那么 B 的访问操作将会返回更新的值。而没有因果关系的 C 进程将会遵循最终一致性的规则(C 在不一致窗口内还是看到是旧值)。

  因果一致性的特定形式。一个进程进行数据更新后,会给自己发送一条通知,该进程后续的操作都会以最新值作为基础,而其他的进程还是只能在不一致窗口之后才能看到最新值。

  读你所写一致性的特定形式。进程在访问存储系统同一个会话内,系统保证该进程可以读取到最新之,但如果会话终止,重新连接后,如果此时还在不一致窗口内,还是可嫩读取到旧值。

  如果一个进程已经读取到一个特定值,那么该进程不会读取到该值以前的任何值。

  为了解决分布式系统的一致性问题,在长期的研究探索过程中,业内涌现出了一大批经典的一致性协议和算法,其中比较著名的有二阶段提交协议(2PC),三阶段提交协议(3PC)和 Paxos 算法。

  Google 2009年 在Transaction Across DataCenter的分享中,对一致性协议在业内的实践做了一简单的总结,如下图所示,这是 CAP 理论在工业界应用的实践经验。

  其中,第一行表头代表了分布式系统中通用的一致性方案,包括冷备、Master/Slave、Master/Master、两阶段提交以及基于 Paxos 算法的解决方案,第一列表头代表了分布式系统大家所关心的各项指标,包括一致性、事务支持程度、数据延迟、系统吞吐量、数据丢失可能性、故障自动恢复方式。

  分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)

  在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。由于存在事务机制,可以保证每个独立节点上的数据操作可以满足ACID。但是,相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲,两台机器理论上无法达到一致的状态。如果想让分布式部署的多台机器中的数据保持一致性,那么就要保证在所有节点的数据写操作,要不全部都执行,要么全部的都不执行。但是,一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以,常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。

  X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。

  通常把一个数据库内部的事务处理,如对多个表的操作,作为本地事务看待。数据库的事务处理对象是本地事务,而分布式事务处理的对象是全局事务。   所谓全局事务,是指分布式事务处理环境中,多个数据库可能需要共同完成一个工作,这个工作即是一个全局事务,例如,一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功,还要依赖与全局事务相关的其它数据库的操作是否成功,如果任一数据库的任一操作失败,则参与此事务的所有数据库所做的所有操作都必须回滚。

  一般情况下,某一数据库无法知道其它数据库在做什么,因此,在一个 DTP 环境中,交易中间件是必需的,由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中。

  XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。

  二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说:两阶段提交主要保证了分布式事务的原子性:即所有结点要么全做要么全不做)

  它可以保证在分布式事务中,要么所有参与进程都提交事务,要么都取消事务,即实现 ACID 的原子性(A)。

  在数据一致性中,它的含义是:要么所有副本(备份数据)同时修改某个数值,要么都不更改,以此来保证数据的强一致性。

  如果参与者成功执行了事务操作,那么就反馈给协调者vote_commit响应,表示事务可以执行,如果没有参与者成功执行事务,那么就反馈给协调者vote_abort响应,表示事务不可以执行.

  Coordinator 收到所有参与者的表决信息,如果所有参与者一致认为可以提交事务,那么 Coordinator 就会发送 GLOBAL_COMMIT 消息,否则发送 GLOBAL_ABORT 消息;对于参与者而言,如果收到 GLOBAL_COMMIT 消息,就会提交本地事务,否则就会取消本地事务。

  2PC 在执行过程中可能发生 Coordinator 或者参与者突然宕机的情况,在不同时期宕机可能有不同的现象。

  这种情况其实比较好解决,只要找一个 Coordinator 的替代者。当他成为新的 Coordinator 的时候,询问所有参与者的最后那条事务的执行情况,他就可以知道是应该做什么样的操作了。所以,这种情况不会导致数据不一致。

  ,协调者就会比对自己的事务执行记录和该参与者的事务执行记录,告诉他应该怎么做来保持数据的一致性。

  还有一种情况是:参与者挂了,Coordinator 也挂了,需要再细分为几种类型来讨论:

  由于这时还没有执行 commit 操作,新选出来的 Coordinator 可以询问各个参与者的情况,再决定是进行 commit 还是 roolback。

  Coordinator 和参与者在第二阶段挂了,但是挂的这个参与者在挂之前还没有做相关操作

  这种情况下,当新的 Coordinator 被选出来之后,他同样是询问所有参与者的情况。只要有机器执行了 abort(roolback)操作或者第一阶段返回的信息是 No 的话,那就直接执行 roolback 操作。如果没有人执行 abort 操作,但是有机器执行了 commit 操作,那么就直接执行 commit 操作。这样,当挂掉的参与者恢复之后,只要按照 Coordinator 的指示进行事务的 commit 还是 roolback 操作就可以了。因为挂掉的机器并没有做 commit 或者 roolback 操作,而没有挂掉的机器们和新的 Coordinator 又执行了同样的操作,那么这种情况不会导致数据不一致现象。

  Coordinator 和参与者在第二阶段挂了,挂的这个参与者在挂之前已经执行了操作。但是由于他挂了,没有人知道他执行了什么操作。

  这种情况下,新的 Coordinator 被选出来之后,如果他想负起 Coordinator 的责任的话他就只能按照之前那种情况来执行 commit 或者 roolback 操作。这样新的 Coordinator 和所有没挂掉的参与者就保持了数据的一致性,我们假定他们执行了 commit。但是,这个时候,那个挂掉的参与者恢复了怎么办,因为他已经执行完了之前的事务,如果他执行的是 commit 那还好,和其他的机器保持一致了,万一他执行的是 roolback 操作呢?这不就导致数据的不一致性了么?虽然这个时候可以再通过手段让他和 Coordinator 通信,再想办法把数据搞成一致的,但是,这段时间内他的数据状态已经是不一致的了!

  同步阻塞:2PC 有几个过程(比如 Coordinator 等待所有参与者表决的过程中)都是同步阻塞的,所有参与该事务操作的逻辑都处于阻塞状态,各个参与者在等待其他参与者响应的过程中,将无法进行其他任何操作。在实际的应用中,这个问题是通过超时判断机制来解决的,但并不能完全解决同步阻塞问题;

  Coordinator 单点问题:实际生产应用中,Coordinator 都会有相应的备选节点;

  数据不一致:这个在前面已经讲述过了,如果在第二阶段,Coordinator 和参与者都出现挂掉的情况下,是有可能导致数据不一致的。

  1.事务询问协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

  2.响应反馈参与者接到CanCommit请求之后,正常情况下,如果其自身认为可以顺利执行事务,则返回Yes响应,并进入预备状态。否则反馈No

  执行事务预提交:如果 Coordinator 接收到各参与者反馈都是Yes,那么执行事务预提交:

  发送预提交请求:Coordinator 向各参与者发送 preCommit 请求,并进入 prepared 阶段;

  事务预提交:参与者接收到 preCommit 请求后,会执行事务操作,并将 Undo 和 Redo 信息记录到事务日记中;

  各参与者向 Coordinator 反馈事务执行的响应:如果各参与者都成功执行了事务操作,那么反馈给协调者 ACK 响应,同时等待最终指令,提交 commit 或者终止 abort,结束流程;

  中断事务:如果任何一个参与者向 Coordinator 反馈了 No 响应,或者在等待超时后,Coordinator 无法接收到所有参与者的反馈,那么就会中断事务。

  发送提交请求:假设 Coordinator 正常工作,接收到了所有参与者的 ack 响应,那么它将从预提交阶段进入提交状态,并向所有参与者发送 doCommit 请求;

  事务提交:参与者收到 doCommit 请求后,正式提交事务,并在完成事务提交后释放占用的资源;

  反馈事务提交结果:参与者完成事务提交后,向 Coordinator 发送 ACK 信息;

  完成事务:Coordinator 接收到所有参与者 ack 信息,完成事务。

  在doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。(其实这个应该是基于概率来决定的,当进入第三阶段时,说明参与者在第二阶段已经收到了PreCommit请求,那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前,收到所有参与者的CanCommit响应都是Yes。(一旦参与者收到了PreCommit,意味他知道大家其实都同意修改了)所以,一句话概括就是,当进入第三阶段时,由于网络超时等原因,虽然参与者没有收到commit或者abort响应,但是他有理由相信:成功提交的几率很大。 )

  中断事务:假设 Coordinator 正常工作,并且有任一参与者反馈 No,或者在等待超时后无法接收所有参与者的反馈,都会中断事务

  发送中断请求:Coordinator 向所有参与者节点发送 abort 请求;

  事务回滚:参与者接收到 abort 请求后,利用 undo 日志执行事务回滚,并在完成事务回滚后释放占用的资源;

  反馈事务回滚结果:参与者在完成事务回滚之后,向 Coordinator 发送 ack 信息;

  中断事务:Coordinator 接收到所有参与者反馈的 ack 信息后,中断事务。

  3PC 虽然解决了 Coordinator 与参与者都异常情况下导致数据不一致的问题,3PC 依然带来其他问题:比如,网络分区问题,在 preCommit 消息发送后突然两个机房断开,这时候 Coordinator 所在机房会 abort, 另外剩余参与者的机房则会 commit。

  而且由于3PC 的设计过于复杂,在解决2PC 问题的同时也引入了新的问题,所以在实际上应用不是很广泛。

  相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

  本文较为粗略地讲述了一致性协议与两种一致性算法,更加系统的理论可以参考后面的分布式系统理论专题文章。 2PC由于BASE理论需要在一致性和可用性方面做出权衡,因此涌现了很多关于一致性的算法和协议。其中...博文来自:gangsijay888的博客

  分布式系统,这早已不是什么新鲜的东西了,在分布式系统的架构设计过程中,往往会存在分布式一致性的问题,经过前人的辛苦探究,提出了二阶段提交协议,三阶段提交协议,Paxos算法等等,用来解决分布式一致性的...博文来自:进步的阶梯的博客

  分布式协议(一致性算法)两阶段提交协议2PC2PC基于如下假设:分布式系统中存在一个协调者和其他参与者,且它们之间网络通信正常。(1)第一阶段:投票阶段首先,协调者向所有参与者发起询问,是否可以执行提...博文来自:不止于技术

  分布式系统中的一致性协议之两阶段提交协议(2PC)     两阶段提交协议是很常见的解决分布式事务的方式,他可以保证分布式事务中,要么所有参与的进程都提交事务成功,要么都取消事务,这样做可以在分布式环...博文来自:chenglinhust的专栏

  二阶段提交协议和三阶段提交协议,实际上他们能解决分布式事务的问题,但是遇到极端情况时,系统会产生阻塞或者不一致的问题,需要运营或者技术人员解决。两阶段及三阶段方案都包含多个参与者、多个阶段实现一个事务...博文来自:孤芳不自赏

  背景在一个分布式系统中,如何保证集群中所有节点中的数据完全相同并且能够对某个提案(Proposal)达成一致是分布式系统正常工作的核心问题,而共识算法就是用来保证分布式系统一致性的方法。然而分布式系统...博文来自:niyuelin1990的博客

  分布式一致性算法paxosamp;raft1paxos算法paxos算法通过多个监督者来增强可靠性通过监督者投票表决状态变化保证所有数据访问都遵从这种表决多数派写客户端写入Wgt;...博文来自:fanc的博客

  第三章:深入浅出理解分布式一致性协议Gossip和Redis集群原理Redis是一个开源的,高性能的key-value的数据库。基于Redis的分布式缓存已经有很多成功的商业应用,其中就包括阿里Aps...博文来自:Jin_Kwok的博客

  前言目前的应用系统,不管是企业级应用还是互联网应用,最终数据的一致性是每个应用系统都要面临的问题,随着分布式的逐渐普及,数据一致性更加艰难,但是也很难有银弹的解决方案,也并不是引入特定的中间件或者特定...博文来自:iamzhongyong的专栏

  在分布式系统中,当一个事务操作需要跨越多个分布式节点的时候,为了保持事务ACID的特征,就需要引入一个称为“协调者”(Coordinator)的组件来统一调度所有分布式节点的执行逻辑,这些...博文来自:江上飞鱼

  1.一致性协议和算法2PC协议:两阶段提交协议3PC协议:Paxos算法:ZAP协议:2.远程通信...博文来自:Owen Fang的博客

  保证分布式系统数据一致性的6种方案转载于: 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体...博文来自:chenglinhust的专栏

  由于毕设和Lab项目需要,最近在看《从paxos到zookeeper分布式一致性原理与实践》,2和3PC算法流程,网上资料很多,就不赘述了。由于书中关于2PC和3PC的缺点的部分描述不容易让人理解,因...博文来自:业精于勤,荒于嬉

  ZookeeperPaxos算法一致性协议    前言Paxos一致性协议可以说是一致性协议研究的起点,也以难以理解闻名。其实协议本身并没有多难理解,它的难理解性主要体现在:为何如此设计协议以及如何证...博文来自:yexiaomodemo的专栏

  多副本一致性主从同步方式主从异步方式Oracle中的应用CAP理论多副本一致性这是分布式一致性算法的一个典型应用场景。在分布式存储系统中经常使用多副本的方式实现容错,这样部分副本的失效不会导致数据的丢...博文来自:chao2016的博客

  今天在看书的时候,看到了分布式事务的一致性问题,就赶紧记下来。一、分布式事务介绍在我们平时写的代码中,我们可以用一个事务包含许多个SQL调用,如果某一个数据库操作发生异常,就可以将之前的SQL操纵全部...博文来自:yanghan1222的博客

  先把我这段时间研究的文章终结下:架构师需要了解的Paxos原理、历程及实战本文主要是介绍了基于Multi-Paxos改进版实现的日志复制方案。Paxos三部曲,和上文同一个作者:[Paxos三部曲之一...博文来自:New World

  简述这里的Consistency(一致性)是指分布式系统中的数据一致性,而非数据库事务ACID特性中的Consistency。CAPCAP(或称布鲁尔定理)指出一个分布式计算系统不可能同时满足以下三点...博文来自:Just do it!

  区块链技术是近几年逐渐变得非常热门的技术,以比特币为首的密码货币其实已经被无数人所知晓,但是却很少有人会去研究它们的底层技术,也就是作为一个分布式网络比特币等加密货币是如何工作的。无论是Bitcoin...博文来自:omnispace的博客

  ZOOKEEPER系列分布式架构与一致性协议首先了解分布式架构先要知道什么是分布式系统根据经典分布式领域的著作《分布式系统概念与设计》一书中指出,分布式系统是:一个硬件或者软件组件分布在不同的网络计算...博文来自:Old Wang的博客

  Raft是分布式环境下的一致性算法,它通过少数服从多数的选举来维持集群内数据的一致性。它与RBFT算法名称有点像,然而Raft算法里不能存在拜占庭节点,而RBFT则能容忍BFT节点的存在。Raft非常...博文来自:陶辉:聚焦分布式系统的程序员

  Paxos,发音近似帕克索斯。问题的提出并发的定义(来自《深入理解计算机系统》):如果逻辑控制流在时间上重叠,那么他们就是并发的。本书的并发,指更新操作的并发,即有多个线程同时更新内存中变量的值。数据...博文来自:lonelymanontheway的博客

  PoW:矿工通过把网络尚未记录的现有交易打包到一个区块,然后不断遍历尝试来寻找一个随机数,使的新区块加上随机数的哈希值满足一定难度的条件,找到满足条件的随机数就相当于确定了区块链最新的一个区块,也相当...博文来自:dhd040805的博客

  早于Flink的异步快照的一个算法,比flink那个有名很多~ (十)简单解释:分布式数据流的异步快照(Flink的核心)非常简单的一个给分布式系统做consistency的快照的算法,可以应对环形流...博文来自:weixin_33801856的博客

  如何实现分布式数据存储一致ZAB协议主要特征:崩溃恢复模式消息广播模式如何利用zookeeper进行选举,画图说明master选举-为其他集群机器服务leader选举-集群启动时期、运行时期为什么会...博文来自:大数据

  说明:以下内容总结自网络1.CAP原理要想数据高可用,就得写多份数据写多分数据就会导致数据一致性问题数据一致性问题会引起性能问题2.一致性模型弱一致性最终一致性(一段时间达到一致性)强一致1、2异步冗...博文来自:followMyInclinations的专栏

  分布式系统基本概念异常类型1服务器down机(随时发生、内存数据丢失(因此需要考虑数据持久化)、down机重启之后要恢复内存信息)2网络异常(消息丢失、消息乱序(UDP)或者网络包数据错误、区域内可通...博文来自:qq100440110的专栏

  两阶段提交协议三阶段提交协议Paxos算法zookeeper一致性协议:zab博文来自:简单生活

  国际开放标准组织OpenGroup定义了DTS(分布式事务处理模型),模型中包含4个角色:应用程序、事务管理器、资源管理器、通信资源管理器四部分。事务处理器是统管全局的管理者,资源处理器和通信资源处理...博文来自:京庐空间

  对于单机系统和集中系统是指一台或多台主计算机组成的中心节点,并数据和业务处理逻辑都集中于这个中心节点上,客户端仅仅负责数据的录入和展示。集中式系统的最大优点就是部署简单,同时不需要考虑分布式系统的协作...博文来自:CWeeYii的专栏

  前言分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的“一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技...博文来自:巨杉数据库

  缓存一致性协议简介缓存一致性协议是为了解决多核以及多处理器的多个缓存之间的数据不一致提出来的,缓存一致性协议分为两种,第一种是基于窥探的协议(snoop-based),第二种是基于目录的协议(dire...博文来自:budzend的博客

  Paxos算法百科Paxos算法是莱斯利·兰伯特(LeslieLamport,就是LaTeX中的La,此人现在在微软研究院)于1990年提出的一种基于消息传递的一致性算法。这个...博文来自:烈火cpm的小笔记

  博文中的内容来源《从Paxos到Zookeeper分布式一致性原理与实践》这一本书,感激不尽。...博文来自:孤芳不自赏

  原文链接 读音【帕克索斯】这是一种基于消息传递的一致性算法。这个算法被认为是类似算法中最...博文来自:teslafzy的博客

  分布式一致性协议Raft原理与实例1.Raft协议1.1Raft简介Raft是由Stanford提出的一种更易理解的一致性算法,意在取代目前广为使用的Paxos算法。目前,在各种主流语言中都有了一些开...博文来自:西代零零发

  当我们在部署redis节点时,用户链接redis存储数据会通过hash算法来定位具体链接那个redis节点,在redis节点数量没有改变的前提下,之前的用户通过hash算法会固定的链接某一台r...博文来自:LC_HYQ的博客

  内容简介 · · · · · · 《Paxos到Zookeeper:分布式一致性原理与实践》从分布式一致性的理论出发,向读者简要介绍几种典型的分布式一致性协议,以及解决分布式一致性问题的思路,其中重点讲解了Paxos和ZAB协议。同时,...

  前一部分(第1章)主要介绍了计算机系统从集中式向分布式系统演变过程中面临的挑战,并简要介绍了ACID、CAP和BASE等经典分布式理论;第二部分(第2~4章)介绍了2PC、3PC和Paxos三种分布式一致性协议,并着重讲解了ZooKeep...

  分布式缓存的一致性Hash的Java实现关于分布式缓存一致性Hash算法的原理,有很多书籍、博客都有详细的介绍。本文主要是想对一致性Hash算法进行一个小小的实现,方便自己更好的理解。算法的具体原理如...博文来自:wojiushimogui的博客

  分布式一致性问题在分布式环境中引入数据复制机制后,不同数据节点间可能出现的,并无法依靠计算机应用程序自身解决的数据不一致情况。其实就是在对一个数据进行更新的同时,必须确保也能够更新其他副本,否则会出现...博文来自:的博客

  Paxos算法1.CAP定理:一个分布式系统不可能同时满足一致性(C),可用性(A)和分区容错性(P)这三个基本需求,最多只能同时满足其中的两项。2.2PC:Prepare(投票);Commit(事务...博文来自:Auspicious Clouds View

  理解和学习分布式一致性协议:raft要点:分布式、一致性、协议什么叫分布式一致性,举个例子?说明:这里的节点指的是相对于client的服务端节点(这个服务端节点可以做存储)一个节点的场景,想想客户端如...博文来自:KuaiLeShiFu的博客

  一、回顾分布式特点  1.集中式特点   一台或多台计算机组成中心接节点,所有的数据都存在中心节点上。Client端只负责数据的展示,Server处理数据的存储和处理。显而易见,优点是结构简单容易部署...博文来自:Weiguang_123的专栏

本文链接:http://ravynhart.com/qiangyizhixing/385.html