精华内容
下载资源
问答
  • 有关一致性,实践中又可以分为:强一致性、单调一致性、最终一致性。 CAP中的C默认就是指:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)。 1、强一致性...

    我们都了解分布式CAP原则,其中的C就是一致性。有关一致性,实践中又可以分为:强一致性、单调一致性、最终一致性。

    CAP中的C默认就是指:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)。

    1、强一致性(Strong Consistency)

    在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求,也是最难实现的。关系型数据库更新操作就是这个案例。

    2, 单调一致性(Monotonic Consistency)

    单调一致性会从读写两个角度有各自的定义。

    单调读一致性

    如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回该值之前的值。(“If a process has seen a particular value for the object any subsequent accesses will never return any previous values”)

    单调写一致性

    系统保证来自同一个进程的写操作顺序执行。(Write operations that must precede other writes are executed before those other writes.)

    3、最终一致性(Eventual Consistency)

    和强一致性相对,在某一时刻用户或者进程查询到的数据可能都不同,但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。

    额外内容:

    zookeeper的一致性

    我们以官方文档为准:(2019-11-17摘录的)

    ZooKeeper is a high performance, scalable service. Both reads and write operations are designed to be fast, though reads are faster than writes. The reason for this is that in the case of reads, ZooKeeper can serve older data, which in turn is due to ZooKeeper's consistency guarantees:
    
    Sequential Consistency : Updates from a client will be applied in the order that they were sent.
    
    Atomicity : Updates either succeed or fail -- there are no partial results.
    
    Single System Image : A client will see the same view of the service regardless of the server that it connects to.
    
    Reliability : Once an update has been applied, it will persist from that time forward until a client overwrites the update. This guarantee has two corollaries:
    
    If a client gets a successful return code, the update will have been applied. On some failures (communication errors, timeouts, etc) the client will not know if the update has applied or not. We take steps to minimize the failures, but the guarantee is only present with successful return codes. (This is called the monotonicity condition in Paxos.)
    Any updates that are seen by the client, through a read request or successful update, will never be rolled back when recovering from server failures.
    Timeliness : The clients view of the system is guaranteed to be up-to-date within a certain time bound (on the order of tens of seconds). Either system changes will be seen by a client within this bound, or the client will detect a service outage.
    
    Using these consistency guarantees it is easy to build higher level functions such as leader election, barriers, queues, and read/write revocable locks solely at the ZooKeeper client (no additions needed to ZooKeeper). See Recipes and Solutions for more details.
    

    简单总结:zk提供的是单调一致性,最终一致性,不是强一致性。 zk的文档清楚强调了ZooKeeper does not guarantee that at every instance in time, two different clients will have identical views of ZooKeeper data.

    原文链接:https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkGuarantees

    mongoDB的一致性

    原文链接:https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

    mongodb提供单调写一致性。
    Monotonic Writes
    MongoDB provides monotonic write guarantees, by default, for standalone mongod instances and replica set.

    For monotonic writes and sharded clusters, see Causal Consistency.
    Write operations that must precede other writes are executed before those other writes.

    后记:我们实际开发业务分布式系统,必须在强一致性和最终一致性中间进行tradeoff。 根据业务要求,进行取舍。强一致性会增加延时(所有实例和副本进行数据同步)和降低可用性(只要有节点无法完成同步数据, 可用性就有问题)。
    现在很多软件直接提供可配置的一致性,用户可以根据业务要求进行配置。 例如微软的cosmos-db。

    参考:
    1, https://hellokangning.github.io/en/post/consistency-in-distributed-system/
    2,https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
    3, https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

    展开全文
  • 强一致性、顺序一致性、弱一致性和共识

    万次阅读 多人点赞 2018-07-21 21:57:37
    可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性(Strict Consistency) 也称为: 原子一致性(Atomic Consistency) 线性一致性(Linearizability Consistency) 两个要求: 任何一次读...


    1. 一致性(Consistency)

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

    1.1 强一致性(Strict Consistency)

    也称为:

    原子一致性(Atomic Consistency)

    线性一致性(Linearizable Consistency)

    两个要求:

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

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

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

    1.2 顺序一致性(Sequential Consistency)

    the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. - - Lamport

    两个要求:

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

    举个栗子:
    这里写图片描述

    Write(x, 4):写入x=4
    Read(x, 0):读出x=0

    1)图a是满足顺序一致性,但是不满足强一致性的。原因在于,从全局时钟的观点来看,P2进程对变量X的读操作在P1进程对变量X的写操作之后,然而读出来的却是旧的数据。但是这个图却是满足顺序一致性的,因为两个进程P1,P2的一致性并没有冲突。从这两个进程的角度来看,顺序应该是这样的:Write(y,2) , Read(x,0) , Write(x,4), Read(y,2),每个进程内部的读写顺序都是合理的,但是这个顺序与全局时钟下看到的顺序并不一样。

    2)图b满足强一致性,因为每个读操作都读到了该变量的最新写的结果,同时两个进程看到的操作顺序与全局时钟的顺序一样,都是Write(y,2) , Read(x,4) , Write(x,4), Read(y,2)。

    3)图c不满足顺序一致性,当然也就不满足强一致性了。因为从进程P1的角度看,它对变量Y的读操作返回了结果0。那么就是说,P1进程的对变量Y的读操作在P2进程对变量Y的写操作之前,这意味着它认为的顺序是这样的:write(x,4) , Read(y,0) , Write(y,2), Read(x,0),显然这个顺序又是不能被满足的,因为最后一个对变量x的读操作读出来也是旧的数据。因此这个顺序是有冲突的,不满足顺序一致性。

    1.3 弱一致性

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

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

    最终一致性

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

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

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

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

    2. 共识(Consensus)

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

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

    展开全文
  • 通俗易懂 强一致性、弱一致性、最终一致性、读写一致性、单调读、因果一致性 的区别与联系什么是一致性一致性的种类导致一致性出现的原因强一致性 与 弱一致性强一致性两个要求弱一致性强一致性和弱一致性举例顺序...

    什么是一致性

    在分布式系统中,一致性(Consistency)是指多副本(Replications)问题中的数据一致性。

    一致性的种类

    • 事务一致性
    • 数据一致性

    本文主要讨论数据一致性(事务一致性指ACID)

    导致一致性出现的原因

    • 数据的分布式存储是导致出现一致性的唯一原因

    强一致性 与 弱一致性

    数据一致性的种类

    • 强一致性(线性一致性):即复制是同步的
    • 弱一致性:即复制是异步的

    强一致性两个要求

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

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

    弱一致性

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

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

    强一致性和弱一致性举例

    例如,对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性
    用户更新网站头像,在某个时间点,用户向主库发送更新请求,不久之后主库就收到了请求。在某个时刻,主库又会将数据变更转发给自己的从库。最后,主库通知用户更新成功。

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

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

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

    顺序一致性

    两个要求:

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

    顺序一致性参考

    最终一致性

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

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

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

    最终一致性的种类

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

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

    一致性(Consistency)

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

    强一致性(Strict Consistency)

    系统中的某个数据被成功更新后,后续任何对该数据的读取操作都将得到更新后的值;

    也称为:原子一致性(Atomic Consistency)线性一致性(Linearizable Consistency)

    两个要求:

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

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

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

    总结:

    • 一个集群需要对外部提供强一致性,所以只要集群内部某一台服务器的数据发生了改变,那么就需要等待集群内其他服务器的数据同步完成后,才能正常的对外提供服务。
    • 保证了强一致性,务必会损耗可用性。

    顺序一致性(Sequential Consistency)

    两个要求:

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

    弱一致性

    系统中的某个数据被更新后,后续对该数据的读取操作可能得到更新后的值,也可能是更改前的值。

    但即使过了“不一致时间窗口”这段时间后,后续对该数据的读取也不一定是最新之;

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

    最终一致性

    是弱一致性的特殊形式,存储系统保证在没有新的更新的条件下,最终所有的访问都是最后更新的值。

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

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

    弱一致性与最终一致性区别

    弱一致性即使过了不一致时间窗口,后续的读取也不一定能保证一致,而最终一致过了不一致窗口后,后续的读取一定一致,才能说清楚弱一致和最终一致的区别

    总结

     

    展开全文
  • 针对Zk一致性,最近看了很多帖子,有的帖子说ZK弱一致性,有的帖子说ZK是强一致性,今天给大家做个正确的解释。 二、问题分析: 1、首先ZK集群的节点类型有三种,leader/follower/observer,其中oberser不参与...
  • C:这里的C指的是强一致性,同一时刻不同的客户端获取到的数据版本都是相同的 A: 可用性,指的是系统会响应客户端的每一个请求 P:分区容忍性,指的是当系统里面某个节点与其他节点通讯切断(导致节点间数据不一致)...
  • 强一致性、弱一致性、最终一致性

    千次阅读 2012-09-11 19:36:04
    强一致性:系统中的某个数据被成功更新后,后续任何对该数据的读取操作都将得到更新后的值; 弱一致性:系统中的某个数据被更新后,后续对该数据的读取操作可能得到更新后的值,也可能是更改前的值。但经过“不一致...
  • zookeeper是强一致性的吗

    千次阅读 2020-10-07 16:08:44
    前端时间面试,面试官问我一个问题,听说你看过zookeeper源码,那你能告诉我zookeeper是不是强一致性的,如果是,又怎么保证数据强一致性的吗? 针对这个问题,我从下面几个角度进行了分析和解答。 什么是一致性 ...
  • 在足球比赛里,一个球员在一场比赛中进三个球,称之...一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分...
  • 1.使用Seata做强一致性分布式事务 还是我们开头提出的问题:如何保证1.1、1.2、1.3要么同时成功,要么同时失败,本小节,使用alibaba seata作为分布式事务的解决方案,达到这个目的。 2.Seata的AT模型介绍 seata...
  • rt。mongodb中分片技术的一致性是强一致性还是最终一致性?底层是用什么算法实现的?
  • HBase 强一致性详解

    千次阅读 2018-01-03 15:30:29
    Hbase是一个强一致性数据库,不是“最终一致性”数据库,官网给出的介绍: “Strongly consistent reads/writes: HBase is not an “eventually consistent” DataStore. This makes it very suitable for tasks ...
  • redis集群是否能保证强一致性?主从服务器之间如何保证一致性的,如果写入主, 没有及时同步到从服务器,那么读取从服务器是不是就不一致了?
  • 在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子。CAP原理中,有三个要素,CAP原理指的是,这三个要素... 一致性就是数据保持一直,可以理解为多个节点中数据的值是一致的,一致性又可以分...
  • 在足球比赛里,一个球员在一场比赛中进三个球,称之...一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行...
  • 介绍内容转载自:http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html https://blog.csdn.net/c289054531/article/details/15337575CAP原理中,有三个要素:一致性(Consistency)可用性(Availability...
  • Mysql 实现主从强一致性和高可用性

    千次阅读 2019-01-04 18:20:22
    在一些对数据有强一致性要求的应用中,数据库宕机导致数据丢失是我们一定要避免的情况。所以保证数据的一致性对我们而言非常重要。 如何做到主从的强一致性呢? 在单机数据库中为了保证事务更新操作不会丢失会...
  • 一致性 hash 分布式过程中我们将服务分散到若干的节点上,以此通过集体的力量提升服务的目的。然而,对于一个客户端来说,该由哪个节点服务呢?或者说对某个节点来说他分配到哪些任务呢? 哈希 考虑到单...
  • Zookeeper - 强一致性系统

    千次阅读 2019-01-09 17:51:47
    Zookeeper - 强一致性系统zookeeper的分布式锁原理概述zookeeper的核心思想与读写机制作为服务发现zookeeper的劣势 zookeeper的分布式锁原理概述 zookeeper 由它的数据结构(Znode),操作原语 和watcher 构成,提供...
  • 在分布式系统中会涉及到CAP原理,来保证数据的一致性, 1.什么是CAP: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理是说这三个要素最多只能同时满足两点,不可能...
  • 分布式事务-tx-lcn 强一致性

    千次阅读 2020-06-23 16:20:24
    a、强一致性,通过TxManager协调控制与事务补偿机制确保数据一致性(主要特点,强一致性,比消息事务强的方面)。 b、易用性,仅需要在业务方法上添加相应注解即可,有个简易的可视化界面。 c、高可用,项目...
  • 利用Docker搭建Mysql 强一致性集群解决方案实战 前言 最近一周在学习Docker技术,以前工作中用过Docker,K8S,实质上对于Docker 的认知只停留在是一种容器技术,对于Docker网络,宿主机目录挂载等内容只停留在使用上...
  • 强一致性算法

    千次阅读 2018-10-15 15:28:06
    分布式系统对fault tolorence的一般...问题:一个节点失败,Master阻塞,导致整个集群不可用,保证了一致性,可用性大大降低。 多数派 每次写入保证写入大于N/2个节点 每次读保证从大于N/2个节点读 问题: 在并发环...
  • 浅谈Hbase 的强一致性

    千次阅读 2014-12-20 19:35:14
    从一开始就知道hbase是CAP中的CP系统,即hbase是强一致性的.我原来一直以为hbase的强一致性是因为底层的HDFS写入时,必须所有副本都写入成功才能返回.最近才想明白,hbase之所以是CP系统,实际和底层HDFS无关,它是CP系统...
  • 一致性(Consistency) 可用性(Availability) 分区容错性(Partition tolerance) 一致性(C):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的; 可用性(A):每一个操作...
  • 分布式强一致性事务

    千次阅读 2018-09-24 22:40:59
     事务是一组操作的执行单元,相对于数据库操作来讲,事务管理的是一组SQL指令,比如增加,修改,删除等,事务的一致性,要求,这个事务内的操作必须全部执行成功,如果在此过程种出现了差错,比如有一条SQL语句没有...
  • CAP原理与最终一致性 强一致性 透析

    千次阅读 2012-09-25 10:00:41
    在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick)。在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子。... 一致性(C):任何一个读操作总是能读取到之前完成的写操作

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 384,896
精华内容 153,958
关键字:

强一致性