精华内容
下载资源
问答
  • 所谓分布式共识(consensus),与CAP理论中的一致性(consistency)其实是异曲同工,就是在分布式系统中,所有节点对同一份数据的认知能够达成一致。保证集群共识的算法就叫共识算法,它与一致性协议这个词也经常...
  • 共识一致

    2021-07-26 00:44:47
    共识一致共识描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。 在实践中,要保障系统满足不同程度的一致性,核心过程往往需要通过共识算法来达成。 共识算法解决的是对某个提案...

    此文为缝合的结果,来源见参考。
    本文为学习所用,如有侵权请告知本人。

    共识与一致性

    共识描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。 在实践中,要保障系统满足不同程度的一致性,核心过程往往需要通过共识算法来达成。

    共识算法解决的是对某个提案(proposal)大家达成一致意见的过程。提案的含义在分布式系统中十分宽泛,如多个事件发生的顺序、某个键对应的值、谁是领导……等等。可以认为任何可以达成一致的信息都是一个提案。对于分布式系统来讲,各个节点通常都是相同的确定性状态机模型(又称为状态机复制问题,state-machine replication),从相同初始状态开始接收相同顺序的指令,则可以保证相同的结果状态。因此,系统中多个节点最关键的是对多个事件的顺序进行共识,即排序。

    一致性往往指分布式系统中多个副本对外呈现的数据的状态。如后面提到的顺序一致性、线性一致性等,描述了多个节点对数据状态的维护能力。

    共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。

    因此,一致性描述的是结果状态共识则是一种手段达成某种共识并不意味着就保障了一致性(这里的一致性指强一致性)。只能说共识机制,能够实现某种程度上的一致性。

    什么是一致性?

    在谈到一致性这个词时,你会想到CAP理论的 consistency,或者 ACID 中的 consistency,或者 cache 一致性协议的 coherence,还是 Raft/Paxos 中的 consensus?

    一致性大概是分布式系统中最容易造成困惑的概念之一,因为它已经被用烂了。在很多中文文献中,都将consistency,coherence,consensus 三个单词统一翻译为”一致性”。因此在谈一致性之前,我认为有必要对这几个概念做一个区分:

    Consensus

    准确的翻译是共识,关注的是多个提议者达成共识的过程。比如 Paxos,Raft 共识算法本质上解决的是如何在分布式系统下保证所有节点对某个结果达成共识,其中需要考虑节点宕机,网络时延,网络分区等分布式中各种问题。共识算法通常应用在复制状态机中,比如 etcd,zookeeper,用于构建高可用容错系统。在这种应用情景下,Raft/Paxos 共识算法被用来确保各个复制状态机(节点)的日志是一致的。类似的,区块链中非常重要的一部分也是共识算法,但通常使用是 POW(Proof of Work) 或 POS(Proof of Stake),这类共识算法通常适合用在公网,去中心化的情形下。

    Coherence

    Coherence 通只出现在 Cache Coherence 一词中,作为”缓存一致性”被提出。我们知道现代的多核 CPU Cache 都是多层结构,通常每个 CPU Core 都有一个私有的 LB/SB, L1, L2 级 Cache,多个 CPU Core 共享一个 L3 Cache。比如 CPU1 修改了全局变量 g 并写入了 CPU1 L1 Cache,此时 CPU2 要读取变量 g,然而 CPU2 L1 Cache 中的 g 仍然是旧值,这里就需要 Cache Coherence (以下简称 CC)机制来保证 CPU2 读取到的一定是 g 的最新值。因此,CC 的本质是让多组 Cache 看起来就像一组 Cache 一样。现代 CPU 都已经实现了 CC,通常程序员也不需要关心 CC 的具体实现策略,目前大部分 CPU 采用的是基于 MESI(Modified-Shared-Invalid-Exclusive) 协议的 CC,这里有一篇参考文章

    解释完了Consensus 和 Coherence,剩下 ACID 和 CAP,两者的 C 都叫做 Consistency,你可能以为这两者应该就是我们常提到的分布式中的一致性了吧。其实并不是,两者也是完全不同的概念。

    ACID Consistency

    ACID 中的一致性是指数据库的一致性约束,ACID 一致性完全与数据库规则相关,包括约束,级联,触发器等。在事务开始之前和事务结束以后,都必须遵守这些不变量,保证数据库的完整性不被破坏,因此 ACID 中的 C 表示数据库执行事务前后状态的一致性,防止非法事务导致数据库被破坏。比如银行系统 A 和 B 两个账户的余额总和为 100,那么无论 A, B 之间怎么转换,这个余额和是不变,前后一致的。

    CAP Consistency

    CAP 理论中的 C 也就是我们常说的分布式系统中的一致性,更确切地说,指的是分布式一致性中的一种: 线性一致性(Linearizability),也叫做原子一致性(Atomic consistency)。

    谈到 CAP,和一致性一样,CAP 理论也是个被滥用的词汇,关于 CAP 的正确定义可参考cap faq

    简单总结CAP理论,在一个分布式的存储系统中,只能Consistency, Availability, Partition三选二,而由于在大规模的分布式系统中,网络不可靠几乎是不可避免的,即Partition网络分区容忍是必选项,因此对系统设计需要在AP(舍弃一致性,可能读出不一致)和CP(发生网络分区时系统不可用,即无法写入)之间权衡。

    很多时候我们会用 CAP 模型去评估一个分布式系统,但这篇文章会告诉你 CAP 理论的局限性,因为 CAP 理论是一个被过度简化的理论(一个只能读写单个数据的寄存器),按照 CAP 理论,很多系统包括 MongoDB,ZooKeeper 既不满足一致性(线性一致性),也不满足可用性(任意一个工作中的节点都要可以处理请求),但这并不意味着它们不是优秀的系统,而是 CAP 定理本身并没有考虑处理延迟(为了做到强一致性的事务同步开销),硬件故障,可读/可写的部分可用性等。这里不再展开,推荐阅读原文。

    正因为 CAP 中对C和A的定义过度理想化,后来又有人提出了BASE 理论,即基本可用(Basically Available)、软状态(Soft State)、最终一致性(Eventual Consistency)。BASE的核心思想是即使无法做到强一致性,但每个应用都可以根据自身的业务特点,采用适当的方法来使系统达到最终一致性(关于最终一致性,这篇亚马逊CTO Werner Vogels的博客值得一读)。显然,最终一致性弱于 CAP 中的 线性一致性。很多分布式系统都是基于 BASE 中的”基本可用”和”最终一致性”来实现的,比如 MySQL/PostgreSQL Replication 异步复制。

    以下我们不再纠结CAP理论本身,而聚焦于分布式一致性的定义和基本概念。

    分布式“顺序”的概念

    要理解分布式一致性,先来谈谈分布式中几个必要的概念: 时间,事件,和顺序。

    分布式系统的时间主要分为物理时间和逻辑时间两种,物理时间是指程序能够直接获取到的 OS 时间,在分布式系统中,由于光速有限,你永远无法同步两台计算机的时间。想要在分布式中仅依靠物理时间来决定事件的客观先后顺序是不可能的。因此分布式系统中,通常使用逻辑时间来处理事件的先后关系。

    分布式中的事件不是瞬间的概念,它有一个起始和结束时间,因此不同进程 发起的事件可能发生重叠,对于发生重叠的事件,我们说它们是并发执行的,在物理时间上是不分先后的。

    理想情况下,我们希望整个分布式系统中的所有事件都有先后顺序,这种顺序就是全序,即整个事件集合中任意两个事件都有先后顺序。但 1.物理时间是很难同步的,2. 网络是异步的,因此在分布式系统中,想要维持全序是非常困难的。不同的节点对两个事件谁先发生可能具有不同的看法,并且大部分时候我只需要知道偏序关系,用于确保因果关系。所谓偏序关系是指:

    1. 如果a和b是同一个进程中的事件,并且a在b前面发生,那么 a->b
    2. 如果a代表了某个进程的消息发送事件,b代表另一进程中针对这同一个消息的接收事件,那么a->b
    3. 如果 a->b且b->c,那么a->c (传递性)

    逻辑时间中的 Lamport Clock和Vector Clock等都可以用于建立偏序关系。

    一致性的分类

    强一致性

    相比较严格一致性,强一致性对于时间上的限制不再那么苛刻。当满足强一致性时,需要满足以下要求 :

    当分布式系统中更新操作完成之后,任何多个进程或线程,访问系统都会获得最新的值。

    强一致性中分为两种情况 :

    • 顺序一致性
    • 线性一致性

    顺序一致性

    Leslie Lamport 在1979年提出了Sequential Consistency。

    顺序一致性是指任何执行结果都是相同的,就好像所有进程对数据存储的读、写操作是按某种序列顺序执行的,并且每个进程的操作按照程序所指定的顺序出现在这个序列中 。

    什么是顺序一致性 ? 我们这里举一个例子

    假设现在存在两个线程A和B,有两个初始值x=y=0,两个线程分别执行以下两条指令。

    线程A线程B
    X=1Y=1
    ThreadA=YThreadB=X

    由于多线程的执行顺序并不一定,所以可能出现几种可能。

    情况1情况2情况3
    X=1Y=1X=1
    ThreadA=YThreadB=XY=1
    Y=1X=1ThreadA=X
    ThreadB=XThread=YThreadB=Y
    结果 : ThreadA = 0 ThreadB = 1结果 : ThreadA = 1 ThreadB = 0结果 : ThreadA = 1 ThreadB = 1

    我们能够看到,上述过程虽然是正常执行,但是由于多个线程的执行顺序不同,最终结果也发生了变化。

    **所谓的顺序一致性,**其实就是规定了一下两个条件:
    (1)单个线程内部的指令都是按照程序规定的顺序(program order)执行的
    (2)多个线程之间的执行顺序可以是任意的,但是所有线程所看见的整个程序的总体执行顺序都是一样的

    可以将满足顺序一致性的分布式系统想象成一个调度器,将多个并发线程的请求看做是多个FIFO请求队列;调度器只能从队列首部逐条取出请求并执行,调度器不能保证多个队列的调度顺序,但是调度器保证所有服务节点对队列的调度顺序是相同的。

    线性一致性(Linearizability)

    也叫做strong consistency或者atomic consistency,于 1987年提出,线性一致性强于顺序一致性,是程序能实现的最高的一致性模型,也是分布式系统用户最期望的一致性。 线性一致性要求 Server 在执行 Operations 时需要满足以下三点:

    1. 瞬间完成(或者原子性)
    2. 任何 Operation 都必须在其发起调用,收到响应之间被执行。
    3. 一旦某个Operatio执行之后,所有后续的Operations都可以观测被操作对象最新的值(如果是写操作的话)。

    如下例,线段表示一个Operation,左端点表示请求时间点,右端点表示相应时间点:
    在这里插入图片描述

    先下结论,上图表示的行为满足线性一致。

    对于同一个对象 x,其初始值为 1,客户端 ABCD 并发地进行了请求,按照真实时间(real-time)顺序,各个事件的发生顺序如上图所示。对于任意一次请求都需要一段时间才能完成,例如 A,“x R() A” 到 “x Ok(1) A” 之间的那条线段就代表那次请求花费的时间段,而请求中的读操作在 Server 上的执行时间是很短的,相对于整个请求可以认为瞬间,读操作表示为点,并且在该线段上。线性一致性中没有规定读操作发生的时刻,也就说该点可以在线段上的任意位置,可以在中点,也可以在最后,当然在最开始也无妨。

    第一点和第二点解释的差不多了,下面说第三点。

    反映出“最新”的值?我觉得三点中最难理解就是它了。先不急于对“最新”下定义,来看看上图中 x 所有可能的值,显然只有 1 和 2。四个次请求中只有 B 进行了写请求,改变了 x 的值,我们从 B 着手分析,明确 x 在各个时刻的值。由于不能确定 B 的 W(写操作)在哪个时刻发生,能确定的只有一个区间,因此可以引入上下限的概念。对于 x=1,它的上下限为开始到事件“x W(2) B”,在这个范围内所有的读操作必定读到 1。对于 x=2,它的上下限为 事件“x Ok() B” 到结束,在这个范围内所有的读操作必定读到 2。那么“x W(2) B”到“x Ok() B”这段范围,x 的值是什么?1 或者 2。由此可以将 x 分为三个阶段,各阶段"最新"的值如下图所示:
    在这里插入图片描述

    清楚了 x 的变化后理解例子中 A C D 的读到结果就很容易了。

    最后返回的 D 读到了 1,看起来是 “stale read”,其实并不是,它仍满足线性一致性。D 请求横跨了三个阶段,而读可能发生在任意时刻,所以 1 或 2 都行。同理,A 读到的值也可以是 2。C 就不太一样了,C 只有读到了 2 才能满足线性一致。因为 “x R() C” 发生在 “x Ok() B” 之后(happen before [3]),可以推出 R 发生在 W 之后,那么 R 一定得读到 W 完成之后的结果:2。

    如果说顺序一致性只保证单个客户端多个请求的执行顺序,线性一致性还保证了多个客户端请求的执行先后顺序;即,如果Client B的请求b发起时间晚于Client A的请求a相应时间,那么Client B的请求b一定晚于Client A的请求a,顺序一致不能给出该保证。

    弱一致性

    弱一致性是指系统并不保证对于从节点的后续访问都会返回最新的更新的值。系统在数据成功写入主节点之后,不保证可以立即从其他节点读到最新写入的值,也不会具体承诺多久读到。但是会尽可能保证在某个时间级别(秒级)之后,让数据达到一致性状态。也就是说,如果能容忍后续的部分或者全部访问不到,则是弱一致性。

    最终一致性

    最终一致性是弱一致性的特定形式,最终一致性保证主从节点之间数据不一致的状态只是暂时的。

    读写一致性

    手机刷虎扑的时候经常遇到,回复某人的帖子然后想马上查看,但我刚提交的回复可能尚未到达从库,看起来好像是刚提交的数据丢失了,很不爽。

    在这种情况下,我们需要读写一致性,也称为读己之写一致性。**它可以保证,如果用户刷新页面,他们总会看到自己刚提交的任何更新。**它不会对其他用户的写入做出承诺,其他用户的更新可能稍等才会看到,但它保证用户自己提交的数据能马上被自己看到。

    如何实现读写一致性?

    最简单的方案,**对于某些特定的内容,都从主库读。**举个例子,知乎个人主页信息只能由用户本人编辑,而不能由其他人编辑。因此,永远从主库读取用户自己的个人主页,从从库读取其他用户的个人主页。

    如果应用中的大部分内容都可能被用户编辑,那这种方法就没用了。在这种情况下可以使用其他标准来决定是否从主库读取,例如可以记录每个用户最后一次写入主库的时间,一分钟内都从主库读,同时监控从库的最后同步时间,任何超过一分钟没有更新的从库不响应查询。

    还有一种更好的方法是,客户端可以在本地记住最近一次写入的时间戳,发起请求时带着此时间戳。从库提供任何查询服务前,需确保该时间戳前的变更都已经同步到了本从库中。如果当前从库不够新,则可以从另一个从库读,或者等待从库追赶上来。

    单调读

    用户从某从库查询到了一条记录,再次刷新后发现此记录不见了,就像遇到时光倒流。如果用户从不同从库进行多次读取,就可能发生这种情况。

    单调读可以保证这种异常不会发生。单调读意味着如果一个用户进行多次读取时,绝对不会遇到时光倒流,即如果先前读取到较新的数据,后续读取不会得到更旧的数据。单调读比强一致性更弱,比最终一致性更强。

    实现单调读取的一种方式是确保每个用户总是从同一个节点进行读取(不同的用户可以从不同的节点读取),比如可以基于用户ID的哈希值来选择节点,而不是随机选择节点。

    *因果一致性

    在本文中阐述因果一致性可能并不是一个很好的时机,因为它往往发生在分区(也称为分片)的分布式数据库中。

    分区后,每个节点并不包含全部数据。不同的节点独立运行,因此不存在**全局写入顺序。**如果用户A提交一个问题,用户B提交了回答。问题写入了节点A,回答写入了节点B。因为同步延迟,发起查询的用户可能会先看到回答,再看到问题。

    为了防止这种异常,需要另一种类型的保证:因果一致性。 即如果一系列写入按某个逻辑顺序发生,那么任何人读取这些写入时,会看见它们以正确的逻辑顺序出现。

    这是一个听起来简单,实际却很难解决的问题。一种方案是应用保证将问题和对应的回答写入相同的分区。但并不是所有的数据都能如此轻易地判断因果依赖关系。如果有兴趣可以搜索向量时钟深入此问题。

    分布式一致性模型的局限性

    分布式一致性模型是被简化过的模型,它将整个分布式系统简化为single-object(如 k-v store, queue),single-op(如 Read/Write, Enqueue/Dequeue),因此有些东西是它没有讨论到的:

    1. single-object: 分布式系统有多个节点,不同的节点可能提供的一致性并不相同,比如连 master 节点可能满足线性一致性,而 slave 节点则不是。
    2. single-op: 前面的例子中,我们简单将事件当做原子性的操作,而在实践中,往往需要事务(2PC, 3PC)来保证整个分布式系统的内部一致性,这个内部一致性和我们前面讨论的外部一致性是有区别的。同样,事务,串行化这些东西和一致性模型也是不同的东西。

    因此一些分布式系统在不同的配置选项或不同的连接状态下,可能体现出不同的一致性。

    参考

    1. 线性一致性和 Raft | PingCAP线性一致性和 Raft | PingCAP
    2. 通俗易懂 强一致性、弱一致性、最终一致性、读写一致性、单调读、因果一致性 的区别与联系 - 知乎 (zhihu.com)
    3. 一致性杂谈 | wudaijun’s blog
    4. 分布式系统理论学习总结 | 无咎 NOTE (wujiu.space)
    展开全文
  • 一致性、顺序一致性、弱一致和共识 提到分布式架构就一定绕不开“一致性”问题,而“一致性”其实又包含了数据一致事务一致性两种情况,本文主要讨论数据一致性(事务一致性指ACID) 复制是导致出现数据...

                       强一致性、顺序一致性、弱一致性和共识

    提到分布式架构就一定绕不开“一致性”问题,而“一致性”其实又包含了数据一致性事务一致性两种情况,本文主要讨论数据一致性(事务一致性指ACID)

    复制是导致出现数据一致性问题的唯一原因。

    如果只用一台数据库来处理所有的写入和读取请求,就一定不存在数据一致性的问题。 但在中大型项目中,我们却经常需要将一份数据存储在超过一台数据库中(即复制),原因有三:

    1、即使一部分数据库出现故障,系统也能正常工作(高可用)

    2、使数据与用户在地理上接近(降低延迟)

    3、扩展可以处理读请求的机器数量(可扩展性、提高读取吞吐量)

    本文假设数据集非常小,每台机器的空间都足够保存整个数据集,否则将会引入一个新的话题“分区”。本文假设使用单领导者的主从复制算法,即只有一台数据库可以处理写请求(称为领导者或主库),所有数据库都可以处理读请求(除主库外其他都是追随者或从库)。

    1. 一致性(Consistency) 

    一致性(Consistency)是指多副本(Replications)问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 

    1.1强一致性(Strict Consistency) 

    也称为:

      原子一致性(Atomic Consistency)

      线性一致性(Linearizable Consistency)

    两个要求:

    • 任何一次读都能读到某个数据的最近一次写的数据。
    • 系统中的所有进程,看到的操作顺序,都和全局时钟下的顺序一致。

    简言之,在任意时刻,所有节点中的数据是一样的。

    例如,对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。

     1.2 顺序一致性(Sequential Consistency)

    两个要求:

    • 任何一次读都能读到某个数据的最近一次写的数据。
    • 系统的所有进程的顺序一致,而且是合理的。即不需要和全局时钟下的顺序一致,错的话一起错,对的话一起对。

     1.3 弱一致性

    数据更新后,如果能容忍后续的访问只能访问到部分或者全部访问不到,则是弱一致性。

    最终一致性就属于弱一致性。

    最终一致性

    不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化。

    简单说,就是在一段时间后,节点间的数据会最终达到一致状态。

    最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以区分为:

     

    1 因果一致性(Casual Consistency)。如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将返回更新后的值,且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问,遵守一般的最终一致性规则。
    2 “读己之所写(read-your-writes)”一致性。当进程A自己更新一个数据项之后,它总是访问到更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例。
    3 会话(Session)一致性。这是上一个模型的实用版本,它把访问存储系统的进程放到会话的上下文中。只要会话还存在,系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统的保证不会延续到新的会话。
    4 单调(Monotonic)读一致性。如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值。
    5 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性,就非常难以编程了。

    2. 共识(Consensus)

    共识问题中所有的节点要最终达成共识,由于最终目标是所有节点都要达成一致,所以根本不存在一致性强弱之分。

    例如,Paxos是共识(Consensus)算法而不是强一致性(Consistency)协议。共识算法没有一致性级别的区分。

     

    另一种说法

    强一致性 与 弱一致性 

    其实只有两类数据一致性,强一致性与弱一致性。强一致性也叫做线性一致性,除此以外,所有其他的一致性都是弱一致性的特殊情况。所谓强一致性,即复制是同步的,弱一致性,即复制是异步的。

    用户更新网站头像,在某个时间点,用户向主库发送更新请求,不久之后主库就收到了请求。在某个时刻,主库又会将数据变更转发给自己的从库。最后,主库通知用户更新成功。

    如果在返回“更新成功”并使新头像对其他用户可见之前,主库需要等待从库的确认,确保从库已经收到写入操作,那么复制是同步的,即强一致性。如果主库写入成功后,不等待从库的响应,直接返回“更新成功”,则复制是异步的,即弱一致性。

    强一致性可以保证从库有与主库一致的数据。如果主库突然宕机,我们仍可以保证数据完整。但如果从库宕机或网络阻塞,主库就无法完成写入操作。

    在实践中,我们通常使一个从库是同步的,而其他的则是异步的。如果这个同步的从库出现问题,则使另一个异步从库同步。这可以确保永远有两个节点拥有完整数据:主库和同步从库。 这种配置称为半同步。

     

    最终一致性

    开篇提到,容忍节点故障只是需要复制的一个原因。另两个原因是可扩展性和降低延迟。

    单领导者的主从复制算法要求所有写入都由单个节点处理,但只读查询可以由任何节点处理。对于读多写少的场景,我们往往创建很多从库,并将读请求分散到所有的从库上去。这样能减小主库的负载,并允许向最近的节点发送读请求。当然这只适用于异步复制——如果尝试同步复制,则单个节点故障将使整个系统无法写入。

    当用户从异步从库读取时,如果此异步从库落后,他可能会看到过时的信息。这种不一致只是一个暂时的状态——如果等待一段时间,从库最终会赶上并与主库保持一致。这称为最终一致性。

    最终两个字用得很微妙,因为从写入主库到反映至从库之间的延迟,可能仅仅是几分之一秒,也可能是几个小时。

    展开全文
  • 共识算法和一致

    千次阅读 2018-04-08 14:48:12
    共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。致性描述的是结果状态,共识则是一种手段。达成某种共识并不意味着就保障了一致性。讲,各个节点通常都是相同的确定性状态机模型(又称为...

    一致性往往指分布式系统中多个副本对外呈现的数据的状态。如前面提到的顺序一致性、线性一致性,描述了多个节点对数据状态的维护能力

    共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程

    致性描述的是结果状态,共识则是一种手段。达成某种共识并不意味着就保障了一致性。

    讲,各个节点通常都是相同的确定性状态机模型(又称为状态机复制问题,state-machine replication),从相同初始状态开始接收相同顺序的指令,则可以保证相同的结果状态。

    系统中多个节点最关键的是对多个事件的顺序进行共识,即排序。

    出现故障(crash或fail-stop,即不响应)但不会伪造信息的情况称为“非拜占庭错误”(non-byzantine fault)或“故障错误”(Crash Fault);

    伪造信息恶意响应的情况称为“拜占庭错误”(Byzantine Fault),对应节点为拜占庭节点。

    解决的是非拜占庭的普通错误情况还是拜占庭错误情况,共识算法可以分为Crash Fault Tolerance(CFT)类算法和Byzantine Fault Tolerance(BFT)类算法。

    于要能容忍拜占庭错误的情况,一般包括PBFT(Practical Byzantine Fault Tolerance)为代表的确定性系列算法、PoW为代表的概率算法等。

    注意 实践中,一致性的结果往往还需要客户端的额外支持,典型情况如通过访问足够多个服务节点来比对验证,确保获取共识后的正确结果。

    提示 不仅在分布式系统领域,实际上在很多领域都存在类似“测不准原理”的约束。

    展开全文
  • 共识(Consensus)和一致性(Consistency)虽然近似,但还是有一些差别: 传统一致性研究 共识研究 侧重 节点共识过程最终达成的稳定状态 分布式节点达成...

     

    共识算法是区块链技术的核心要素,也是近年来分布式系统研究的热点。共识(Consensus)和一致性(Consistency)虽然近似,但还是有一些差别:

     

    传统一致性研究

    共识研究

    侧重

    节点共识过程最终达成的稳定状态

    分布式节点达成一致的过程及其算法

    是否考虑拜占庭容错

    大多不考虑拜占庭容错问题,即假设不存在恶意篡改和伪造数据的拜占庭节点

    考虑拜占庭容错问题

    应用场景

    节点数量有限且相对可信的分布式数据库环境

    运行在复杂、开放和缺乏信任的环境, 节点数量多,可能存在恶意拜占庭节点

    展开全文
  • 一致和共识区别 一致性往往指分布式系统中多个副本对外呈现的数据的状态。共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。因此,一致性描述的是结果状态,共识则是一种手段。 在...
  • 到这一步仅仅是达到了数据共识,如果要做到数据一致,还需要client的参与。在数据更新提案请求批准时,只要多数派回应,leader就决定提交,但是读的时候还是有可能会读出多种结果,所以这里就需要通过某种机制来...
  • 区块链的共识算法分布一致性算法 转载自某要花钱的网课
  • 本篇文章我们通过逻辑时钟这样的引子,来看看一致性、共识和逻辑时钟之间的关系,为之后打下思考基础
  • 同时有一个客户端可以发送数据到服务器,在一个节点上达成一致共识是很容易的: 但是如果我们有很多个节点该如何达成共识?这个问题就叫做分布式共识 协议概述 Raft是实现分布式共识的协议。让我们看一下它是如何...
  • 一致共识 ppt

    2018-12-16 20:22:07
    介绍区块链中的共识机制。 私有链(paxos, raft); 联盟链(pbft);公有链(pow)
  • Raft是分布式环境下的一致性算法,它通过少数服从多数的选举来维持集群内数据的一致性。它与RBFT算法名称有点像,然而Raft算法里不能存在拜占庭节点,而RBFT则能容忍BFT节点的存在。Raft非常类似于paxos协议(参见我...
  • 分布式一致性与共识算法

    万次阅读 2018-02-14 18:16:07
    无论是 Bitcoin、Ethereum 还是 EOS,作为一个分布式网络,首先需要解决分布式一致性的问题,也就是所有的节点如何对同一个提案或者值达成共识,这一问题在一个所有节点都是可以被信任的分布式集群中都是一个比较难....
  • 摘要:本篇文章是【区块链之技术进阶】的第七篇文章,在之前的文章中咱们多多少少提及了共识算法等相关知识,但是却没有具体地更加深入地了解,本文就为大家掰一掰区块链共识机制与分布式一致性算法,两者究竟有什么...
  • 区块链:3、共识算法 PoS机制 概念、三个关键要素、POS过程、共识记账、能否解决拜占庭将军问题
  • Ripple达成一致共识图解

    千次阅读 2018-05-01 12:51:59
    一致共识是个持续迭代的过程。服务器发出一组交易的提案,然后其他从对端接收到(提案)的服务器也发出自己的提案。这里我们有某一台在Ripple网络中的服务器的抽象化图解。在中间显示了关闭包(Closing Bun...
  • 从分布式一致性到共识机制(一)Paxos算法 从分布式一致性到共识机制(二)Raft算法 从分布式一致性到共识机制(三)拜占庭问题
  • 从分布式一致性算法到区块链共识算法(二) 注意:本文所介绍内容来源于文献:[1]靳世雄,张潇丹,葛敬国,史洪彬,孙毅,李鸣,林业明,姚忠将.区块链共识算法研究综述[J].信息安全学报,2021,6(02):85-100. 本文是对该...
  • 从分布式一致性算法到区块链共识算法 一致性问题 一致性问题是分布式领域最为基础也是最重要的问题。 如果分布式系统能实现“一致”, 对外就可以呈现为一个完美的、可扩展的“虚拟节点”,相对物理节点具备更优越...
  • 分布式一致性是一个很“古典”的话题,即在分布式系统中,如何保证系统内的各个节点之间数据的一致性或能够就某个提案达成一致。这个问题想必对于很多技术同学而言并不陌生,几乎在所有的分布式系统中都会遇到,比如...
  • 思考一个问题,共识和数据一致性有什么区别? 二者很像,很多场合甚至可以互换,但我们可也以体会到细微的区别: 数据一致性,更像结果目标,是系统理想的状态,但不定义怎么达到这个状态。 共识,也是结果目标...
  • 说的简单明了他们说你是泛泛而谈,算法这东西是讲明白的吗?自己不动手光想听别人...2000年,Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论:分布式系统不可能同时满足一致性(Consistency),可用性(Availa
  • 共识协议中“一致性”的分类1.一致性的定义2.一致性的分类强一致性弱一致性最终一致性参考文章: 1.一致性的定义 在分布式系统中,运行着多个相互关联的服务节点。 一致性是指分布式系统中的多个服务节点,给定一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 34,776
精华内容 13,910
关键字:

共识和一致共识的区别