精华内容
下载资源
问答
  • 2020-11-01 17:10:37

    什么是一致性

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

    一致性的种类

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

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

    导致一致性出现的原因

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

    强一致性 与 弱一致性

    数据一致性的种类

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

    强一致性两个要求

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

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

    弱一致性

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

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

    强一致性和弱一致性举例

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

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

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

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

    顺序一致性

    两个要求:

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

    顺序一致性参考

    最终一致性

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

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

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

    最终一致性的种类

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

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

    展开全文
  • 强一致性 弱一致性 最终一致性

    千次阅读 2019-10-02 17:58:48
    在足球比赛里,一个球员在一场比赛中进三个球,称之...一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分...

    在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick)。在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子。CAP原理中,有三个要素:

    • 一致性(Consistency)
    • 可用性(Availability)
    • 分区容忍性(Partition tolerance)

    CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分布式架构设计时,必须做出取舍。而对于分布式数据系统,分区容忍性是基本要求,否则就失去了价值。因此设计分布式数据系统,就是在一致性和可用性之间取一个平衡。对于大多数web应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是目前多数分布式数据库产品的方向。

    当然,牺牲一致性,并不是完全不管数据的一致性,否则数据是混乱的,那么系统可用性再高分布式再好也没有了价值。牺牲一致性,只是不再要求关系型数据库中的强一致性,而是只要系统能达到最终一致性即可,考虑到客户体验,这个最终一致的时间窗口,要尽可能的对用户透明,也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的,“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

    最终一致性(eventually consistent)

    对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。一致性是因为有并发读写才有的问题,因此在理解一致性的问题时,一定要注意结合考虑并发读写的场景。

    从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。如果能容忍后续的部分或者全部访问不到,则是弱一致性。如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

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

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

    上述最终一致性的不同方式可以进行组合,例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看,这两者的组合,读取自己更新的数据,和一旦读取到最新的版本不会再读取旧版本,对于此架构上的程序开发来说,会少很多额外的烦恼。

    从服务端角度,如何尽快将更新后的数据分布到整个系统,降低达到最终一致性的时间窗口,是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统:

    • N — 数据复制的份数
    • W — 更新数据是需要保证写完成的节点数
    • R — 读取数据的时候需要读取的节点数

    如果W+R>N,写的节点和读的节点重叠,则是强一致性。例如对于典型的一主一备同步复制的关系型数据库,N=2,W=2,R=1,则不管读的是主库还是备库的数据,都是一致的。

    如果W+R<=N,则是弱一致性。例如对于一主一备异步复制的关系型数据库,N=2,W=1,R=1,则如果读的是备库,就可能无法读取主库已经更新过的数据,所以是弱一致性。

    对于分布式系统,为了保证高可用性,一般设置N>=3。不同的N,W,R组合,是在可用性和一致性之间取一个平衡,以适应不同的应用场景。

    • 如果N=W,R=1,任何一个写节点失效,都会导致写失败,因此可用性会降低,但是由于数据分布的N个节点是同步写入的,因此可以保证强一致性。
    • 如果N=R,W=1,只需要一个节点写入成功即可,写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据,因此是弱一致性。这种情况下,如果W<(N+1)/2,并且写入的节点不重叠的话,则会存在写冲突
    展开全文
  • 可以分为强一致性、顺序一致性与弱一致性。 强一致性(Strict Consistency) 系统中的某个数据被成功更新后,后续任何对该数据的读取操作都将得到更新后的值; 也称为:原子一致性(Atomic Consistency)线性一致...

    一致性(Consistency)

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

    强一致性(Strict Consistency)

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

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

    两个要求:

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

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

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

    总结:

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

    顺序一致性(Sequential Consistency)

    两个要求:

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

    弱一致性

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

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

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

    最终一致性

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

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

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

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

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

    总结

     

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

    万次阅读 多人点赞 2018-07-21 21:57:37
    可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性(Strict Consistency) 也称为: 原子一致性(Atomic Consistency) 线性一致性(Linearizability Consistency) 两个要求: 任何一次读...
  • 1. 什么是/弱一致性? ​对于分布式系统而言,一致性是探讨当前系统内的一份逻辑数据存在多个物理的数据副本时,对其执行读写操作会产生什么样的结果。在数据库领域,“一致性”与事务密切相关,又进一步细化到...
  • 在足球比赛里,一个球员在一场比赛中进三个球,称之...一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行...
  • 针对Zk一致性,最近看了很多帖子,有的帖子说ZK弱一致性,有的帖子说ZK是强一致性,今天给大家做个正确的解释。 二、问题分析: 1、首先ZK集群的节点类型有三种,leader/follower/observer,其中oberser不参与...
  • 1.使用Seata做强一致性分布式事务 还是我们开头提出的问题:如何保证1.1、1.2、1.3要么同时成功,要么同时失败,本小节,使用alibaba seata作为分布式事务的解决方案,达到这个目的。 2.Seata的AT模型介绍 seata...
  • 在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子。CAP原理中,有三个要素,CAP原理指的是,这三个要素... 一致性就是数据保持一直,可以理解为多个节点中数据的值是一致的,一致性又可以分...
  • zookeeper是强一致性的吗

    千次阅读 2020-10-07 16:08:44
    前端时间面试,面试官问我一个问题,听说你看过zookeeper源码,那你能告诉我zookeeper是不是强一致性的,如果是,又怎么保证数据强一致性的吗? 针对这个问题,我从下面几个角度进行了分析和解答。 什么是一致性 ...
  • 在集群环境中,主从复制,如ZK(Paxos)、Redis(Raft)等强一致性算法的影子 此外,“一致性哈希”,“最终一致性”这些名词里的“一致性”也有不同的涵义。 参考:...
  • 在分布式系统中会涉及到CAP原理,来保证数据的一致性, 1.什么是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...
  • 如何保证DB和Redis的强一致性?

    千次阅读 2022-04-24 23:10:03
    如何保证DB和Reids的强一致性? 场景描述 在实际开发场景中经常遇到一些需求,在数据库操作成功后,需要进行一些其他操作:更新缓存或者更新搜索引擎中的索引等。如何保证数据库更新和这些其他操作的一致性。以DB与...
  • 分布式强一致性事务

    千次阅读 2018-09-24 22:40:59
     事务是一组操作的执行单元,相对于数据库操作来讲,事务管理的是一组SQL指令,比如增加,修改,删除等,事务的一致性,要求,这个事务内的操作必须全部执行成功,如果在此过程种出现了差错,比如有一条SQL语句没有...
  • redis集群是否能保证强一致性?主从服务器之间如何保证一致性的,如果写入主, 没有及时同步到从服务器,那么读取从服务器是不是就不一致了?
  • 分布式事务-tx-lcn 强一致性

    千次阅读 2020-06-23 16:20:24
    a、强一致性,通过TxManager协调控制与事务补偿机制确保数据一致性(主要特点,强一致性,比消息事务强的方面)。 b、易用性,仅需要在业务方法上添加相应注解即可,有个简易的可视化界面。 c、高可用,项目...
  • 分布式事务-seata AT模式-强一致性

    千次阅读 2020-07-03 14:48:57
    1.参考链接:https://github.com/seata/seata-samples/tree/master/springcloud-eureka-feign-mybatis-seata; ... 3.关键组件: eureka、seate服务器、微服务1(hello)、微服务2(feign-consumer) ...
  • 强一致性、弱一致性、最终一致性

    千次阅读 2015-09-27 22:01:39
    在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick)。在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子。...一致性(Consistency)可用性(Availabil
  • Zookeeper - 强一致性系统

    千次阅读 2019-01-09 17:51:47
    Zookeeper - 强一致性系统zookeeper的分布式锁原理概述zookeeper的核心思想与读写机制作为服务发现zookeeper的劣势 zookeeper的分布式锁原理概述 zookeeper 由它的数据结构(Znode),操作原语 和watcher 构成,提供...
  • 强一致性算法Paxos、Raft、ZAB

    千次阅读 2020-03-23 16:10:18
    在B站上一个讲这三个算法的视频网址https://www.bilibili.com/video/av21667358 Paxos协议 Basic paxos算法中,分为4种...心跳是Leader向Follower发送,而ZAB方向与之相反 参考理解分布式一致性:Paxos协议之Multi-Paxos
  • 一致性(Consistency) 可用性(Availability) 分区容错性(Partition tolerance) 一致性(C):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的; 可用性(A):每一个操作...
  • Mysql 实现主从强一致性和高可用性

    千次阅读 2019-01-04 18:20:22
    在一些对数据有强一致性要求的应用中,数据库宕机导致数据丢失是我们一定要避免的情况。所以保证数据的一致性对我们而言非常重要。 如何做到主从的强一致性呢? 在单机数据库中为了保证事务更新操作不会丢失会...
  • 而在迭代时,ConcurrentHashMap使用了不同于传统集合的快速失败迭代器(见之前的文章《JAVA API备忘---集合》)的另一种迭代方式,我们称为弱一致迭代器。在这种迭代方式中,当iterator被创建后集合再发生改变就不再...
  • 伪代码场景用购买某种商品1件(原库存1000),增加20积分,扣除100元余额设计说明通过日志表来完成TCC。修改库存,余额表要先添加一条记录到他们的日志表里,表要记录TCC状态。 通过唯一业务Code去重,保证幂等。...
  • 关于缓存一致性问题的思考

    千次阅读 2022-04-08 17:36:17
    缓存一致性问题是实际工作中很少很少遇见但面试过程中经常出现的一个问题。本文主要谈一下自己对缓存一致性问题的一些思考,而不是面试科普文。
  • 分布式系统中的一致性模型

    千次阅读 2022-04-15 09:30:34
    一致性模型本质上是进程与数据存储的约定:如果进程遵循某些规则,那么进程对数据的读写操作都是可预期的。
  • 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 ...
  • ZooKeeper能保证任何时刻读到的数据绝对一致吗? Zookeeper的特点就是,分布式,高可用,...也就是说可用性和一致性是Zookeeper的关键特性,作为一个消息的中间商,做了一个可靠的信息传递和存储的角色。 但是了解下ZooKeep

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 442,938
精华内容 177,175
关键字:

强一致性

友情链接: lmm_5unknown.zip