精华内容
下载资源
问答
  • 强一致性 弱一致性 最终一致性
    千次阅读
    2019-10-02 17:58:48

    在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(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,并且写入的节点不重叠的话,则会存在写冲突
    更多相关内容
  • 使用RabbitMQ+延迟队列实现分布式事务的最终一致性方案,demo以典型的订单+库存系统为例
  • 有关一致性,实践中又可以分为:强一致性、单调一致性、最终一致性。 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/

    展开全文
  • ZooKeeper能保证任何时刻读到的数据绝对一致吗? Zookeeper的特点就是,分布式,高可用,...也就是说可用性和一致性是Zookeeper的关键特性,作为一个消息的中间商,做了一个可靠的信息传递和存储的角色。 但是了解下ZooKeep

    Zookeeper能保证任何时刻读到的数据绝对一致吗?

    Zookeeper的特点就是,分布式,高可用,自带容错,所有节点读到的数据都是一致的。使用的场景通常是微服务的注册中心,或者一些分布式的开源软件用来保存元数据,或者监测生命状态。

    这些使用场景默认Zookeeper永远是可用的,而且去Zookeeper集群旗下的每家分号,获取的数据都是一样的,通常情况下也确实如此。
    也就是说可用性一致性是Zookeeper的关键特性,作为一个消息的中间商,做了一个可靠的信息传递和存储的角色。

    但是了解下Zookeeper的ZAB协议,特别是写入部分和读部分,发现了一点细节,Zookeeper不能保证永远读到最新的数据,这里简述下Zookeeper读写过程、

    写过程
    Leader接收Client的写请求,广播给其他Follower节点,其他节点将消息加入待写队列,向Leader发送成功消息,过半的Follower同意后,Leader向所有节点发送提交消息,Follower会落实写请求

    读过程
    Client直接访问一台 Zookeeper获取信息

    也就是说,如果在写的过程中,过半的follower同意了,这条消息通过写入,但有一台Zookeeper和Leader无法通信了,或者因为磁盘,内存等原因拒绝写入了此时一个client来这个zookeeper节点取数据,那么取的和最新版本的就不一致

    Zookeeper保证了怎样的一致性

    有些地方会写Zookeeper不保证强一致性,保证了最终一致性。
    只是从字面来看,最终一致性听上去也没错,但是从细节来看,还是不准确或者说不对。

    首先,CAP中,Zookeeper保证的是CP还是AP。
    随便搜一个科普CAP理论和Zookeeper关系的文章
    Zookeeper和CAP理论及一致性原则
    可以知道,Zookeeper保证的是CP,即一致性(Consistency)分区容错性(Partition-Tolerance)
    牺牲了部分可用性(Available),
    强一致性的条件下,必须先暂停服务,达成一致性再提供服务,这个同步过程中,请求得不到回应,降低了可用性
    而Zookeeper作为协调服务,需要在大部分情况下都可用,不能出现太明显的不可用,因此明显不可用的时段只有Leader选举阶段,此时无法写入,
    Zookeeper选举机制本身是一种快速选举的机制,触发选举的时候有崩溃恢复启动选举 两种情况,所以这个问题也可以控制。

    从上文简述的写入机制来看,Zookeeper是通过Leader来让各节点的写入达到一致性
    而达成的一致性,但是这个过程中为了快速响应客户端,只要follower过半回应即可。
    下面说一下几种一致性的概念
    强一致性:又称线性一致性(linearizability ),
    1.任意时刻,所有节点中的数据是一样的,
    2.一个集群需要对外部提供强一致性,所以只要集群内部某一台服务器的数据发生了改变,那么就需要等待集群内其他服务器的数据同步完成后,才能正常的对外提供服务
    3.保证了强一致性,务必会损耗可用性

    弱一致性:
    1.系统中的某个数据被更新后,后续对该数据的读取操作可能得到更新后的值,也可能是更改前的值。
    2.即使过了不一致时间窗口,后续的读取也不一定能保证一致。

    最终一致性:
    1.弱一致性的特殊形式,不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化
    2.存储系统保证在没有新的更新的条件下,最终所有的访问都是最后更新的值

    顺序一致性:
    1.任何一次读都能读到某个数据的最近一次写的数据。
    2.系统的所有进程的顺序一致,而且是合理的。即不需要和全局时钟下的顺序一致,错的话一起错,对的话一起对
    (目前网上能查到的原话)

    前三种应该都好理解。强一致性就是在任意时刻,所有节点中的数据都是一样的

    弱一致性就是可能访问的到更新后的值,也可能访问不到。

    最终一致性,不保证任何节点都是相同的,也就是说各节点的数据版本可能完全是混乱的,a节点是1,b节点是2,c节点是3,然后a节点更新到2,b节点更新到3,但能保证在没有更新后达成一致。

    顺序一致性第一句比较好理解,第二句就比较抽象了,字看的懂,但还是不知道具体说啥,经过查阅资料

    123
    来看这张水印重重的图,
    最上面的(a),
    两个进程p1和p2,p1先写了x=4,然后进行读操作,读了y=2,
    p2写了y=2,然后进行读操作,读了x=0

    从全局时钟来看,p2对x的读取在P1的写操作之后,但是数值却是旧的,也就是说这个系统中两个进程并不是每个时刻都能保持数值的一致,不满足强一致性。
    但是如果从进程角度来看,我p2执行的操作,与p1并不冲突,如果p2先执行,p1后执行,
    p2写了y=2,读到x=0,之后p1才写了x=4,并且读到的y确实也是2
    ,
    那他就符合顺序一致性,而且也确实读到了某个数据的最近一次写的数据

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

    ©可以看出,假如p2在先,那么p1读到的y值应该是2而不是0。假如p1在先,那么p2读到的x值应该应该是4而不是0。所以他不符合顺序一致性,更不符合强一致性。

    再说下Java内存模型中顺序一致性,如果对多线程并发有理解,可以结合下来理解

    顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型,它为程序员提供了极强的内存可见性保证。顺序一致性内存模型有两大特性:
    一个线程中的所有操作必须按照程序的顺序来执行
    (不管程序是否同步)所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中,每个操作都必须原子执行且立刻对所有线程可见

    这里的顺序一致性,讲的是一种多线程并发执行下理想情况,包含两种要求
    1.线程中的操作必须按照程序的顺序执行,也就是说,不能自己自作主张,更换执行顺序
    2.线程中的操作是原子性的,执行了就是执行了,没执行就是没执行,不存在中间状态,而且一旦执行,其他变量应该立刻可见

    联系到zookeeper,说点结论
    1.各节点的数据更新必须按照顺序进行
    2.数据写入执行情况,数据版本应对其他节点可见(leader能知道写入是否成功)。

    结合以上,你会发现,zookeeper并不是最终一致性,而是顺序一致性。
    1.最终一致性的特点是,无法保证任意节点在同一时间某份数据是相同的,但是最终在没有新的更新时会达成一致
    而Zookeeper所有节点的数据版本都是递增的,可能会有某个节点因故障版本低于大多数,但是是有序的,不会出现各自增长的情况

    比如,Zookeeper节点可能会出现4台数据是version 5,一台数据是version4。但是不会是5台机器各自更新。

    所以这里对顺序一致性的定义是
    1.任何一次读都能读到某个数据的最近一次写的数据

    2.对其他节点之前的修改是可见(已同步)且确定的,并且新的写入建立在已经达成同步的基础上

    结论:Zookeeper写入是强一致性,读取是顺序一致性。

    然后这只是基于现有的资料的一点思考,如果以后发现有不对的,随时修改。

    参考:
    Zookeeper并不保证读取的是最新数据
    强一致性、顺序一致性、弱一致性和共识
    深入理解Java内存模型(三)——顺序一致性
    ZooKeeper和CAP理论及一致性原则
    分布式架构之Consistency(一致性、强一致性,弱一致性,顺序一致性,最终一致性)

    ============
    作者:花灯渔火
    版权归作者所有,转载请注明出处

    展开全文
  • 本地消息表是最终一致性的方法,之前的实物补偿是强一致性方法,其区别可以追溯到CAP理论和BASE理论。大白话来说,强一致性保证不存在数据不一致的脏时间,最终一致性可能存在脏时间。 消息队列 消息队列实际上是...

    一、单机事务的延伸

    所谓单机事务,可以理解为单体应用和数据库这两个东西之间实现原子操作的一种方式,其核心要求是实现ACID四种特性。
    对于这些特性,有疑问的同学可以看看这篇:聊聊Mysql的事务、Spring中的@Transaction

    单体应用中很好的实现了ACID问题,那么当这个问题延伸到微服务之中的时候呢?首先我们要先明确微服务应用和数据库之间的基本架构。
    在这里插入图片描述
    简单来说,服务与数据库是一对一的,同一个服务不会直接去调用其他服务的数据库,而是通过调用其他服务来操作数据库。这样的架构是当下流行的,符合单一职责的。

    现在再来看事务的问题,我们有个下单操作,需要同时操作订单库和商品库。应该如何保证这个下单操作的事务?

    举个实际的例子来理解这个问题,我们在订单服务开启了事务,在事务中RPC调用了商品服务,成功操作了商品库数据。而此时订单服务继续往下操作自身数据时异常了,回滚本地操作。请问,此时商品库的数据回滚了吗?

    答案显然是没有,订单服务的事务只是针对订单库的,无法影响到RPC调用的商品服务,更无法影响到商品库的数据使其回滚。

    这就是分布式事务所面临的的问题。

    二、九十年代的XA事务

    XA事务是一种用来分布式事务的解决方案,但是它并不是符合上述微服务架构的分布式事务解决方案
    此话怎讲?来看下面这个图。
    在这里插入图片描述
    大家会发现,怎么是单体应用啊?是的,XA事务正是用来解决单客户端,多数据源问题的
    XA事务在九十年代提出,由数据库大家族一起实现,无论是哪种关系型数据库,都去实现XA协议,做到在一个客户端开启事务就等同于在连接的所有数据库开启事务。这就是XA事务的初衷。

    这么看起来,XA好像没什么用,不,它有用,前人栽树后人乘凉,分布式事务框架Seata就利用了XA这一数据库特性实现了Seata框架本身的`XA模式`。
    

    XA事务原理

    XA事务是基于2PC(两阶段提交协议)实现的,它通过XID来统一标识一次事务。

    1. 客户端在一阶段(prepare阶段),对所有数据源发起perpare请求,所有数据源开启自身XA事务、执行sql,并回复客户端自己准备好了。若此时有任何一个数据源未能成功反馈成功,则本次事务将会进入Rollback阶段。
    2. 二阶段(Rollback阶段),在一阶段中,有任何一个数据源回复失败,客户端都会放弃本次操作,并通知其他所有数据源,进行事务回滚操作,本次操作完成。
    3. 二阶段(Commited阶段),在一阶段中,所有数据源都回复成功,客户端就对所有数据源发起Commited,数据源接收到Commited信号,commited本地事务,本次操作完成。

    实际上,上面的客户端官方定义是TM(Transaction Management,TM会在客户端自动管理各个数据源的XA事务)数据源的官方名字是RM(Resource Management)

    XA事务很简单,实际上也存在网络超时、锁资源之类的问题,但是根源上,当下微服务架构它的设计思想不符,我们无法轻易用上它

    那么分布式事务到底该怎么实现呢?

    三、常见的分布式事务方案

    事务补偿

    回想我们之前纠结的问题,订单服务自身回滚了,商品服务却没有回滚,影响了事务的原子性,那么我们在订单服务回滚的时候,手动写一段代码将商品服务的操作回滚是不是也可以?
    这确实是一种常见的手法。也符合要么全部成功、要么全部失败的原则,但是它也存在一些问题。
    缺点: 最令人诟病的是要自定义回滚操作,订单服务RPC调用的远程服务服务越多,要补偿的代码逻辑就越多。

    本地消息表

    本地消息表是ebay提出的解决方案,使用一张消息表来记录本次事务,RPC调用方通过不断轮询消息表来查看是否需要自己做点儿什么。

    需要注意的是

    1. 在订单服务(事务开启方)需要在一个本地事务中进行本地数据操作和消息表操作,保证本地数据操作和消息表操作的原子性。
    2. 订单服务完成数据后,商品服务多久完成此次事务取决于商品服务的轮询时间间隔,也就是说,该方法能保证最后订单库和商品库数据都是对的,但是不能保证现在他们就都是对的。这就是数据的最终一致性。
    3. 我们不考虑商品服务的业务逻辑异常问题,这属于bug。

    本地消息表是最终一致性的方法,之前的实物补偿是强一致性方法,其区别可以追溯到CAP理论和BASE理论。大白话来说,强一致性保证不存在数据不一致的脏时间,最终一致性可能存在脏时间

    消息队列

    消息队列实际上是本地消息表的另一种实现方式,只是将本地消息表的载体替换成了消息队列。

    1. 使用消息队列,我们同样需要保证发送消息和本地数据操作的原子性。这一点可以用事务消息来保证。比如rocketMQ,它的事务消息可以保证从生产者发送到消息最终在Broker落盘的这一系列中间操作都是原子性的。 事务消息细节有兴趣的同学可以直接去了解,这一部分还是蛮多的。
    2. 相较于本地消息表,商品服务(消费者)是被动的接收消息并消费,不再需要不断的轮询本地消息表,这是一个优点。
    3. 我们同样不考虑商品服务的业务逻辑异常问题,这是bug。但是我们要考虑消费者重复消费的问题,这是使用mq的常识。

    四、分布式事务框架Seata

    seata本质上是独立出来一个节点TC(Transaction coordinator,协调者),这个协调者来进行与所有节点的沟通,TM只需要告诉TC自己要开启事务,要提交/回滚事务,剩下的都由协调者来完成,大大减轻了TM和开发者的负担。
    (偷一张Seata官微的原图)在这里插入图片描述

    AT模式

    一阶段(prepare):所有RM解析当前sql,自动生成回滚日志。执行sql,此时数据库相关数据已被改写。
    二阶段(rollback): 所有RM根据之前的回滚日志进行反向sql,将数据库相关数据再改回来。
    二阶段(commit):所有RM清除本次事务无关数据,如回滚日志。

    缺点:解析sql损耗性能、无法保证脏读(AT默认是读未提交,如果设定读已提交会性能直线下降)。

    TCC模式

    AT模式的人工版、也就是我们上面提到的事务补偿。AT模式的回滚是自动通过sql解析出来的反向sql,而TCC模式完全把perpare、rollback、commit三个方法的实现全都交给开发者。
    缺点:脏读问题同上、代码量可能会恶心死人……

    SAGA模式

    seata官方意思是长事务的解决方案,saga模式不再依赖两阶段提交,而是依赖状态机。
    简单来说,事务一旦start,各个RM按照顺序,一个一个执行自己的逻辑,当其中有一个RM执行失败,之前已经执行的RM都需要进行回滚。
    当然,SAGA模式的正向业务逻辑反向回滚逻辑也是开发者自己来写的。

    XA模式

    Seata的XA模式依赖于数据库原生的XA事务,借助Seata自身独有的TC,实现如下架构方式使用XA事务。
    在这里插入图片描述

    展开全文
  • MQ消息最终一致性解决方案

    千次阅读 2019-09-30 10:00:21
    多个服务之间使用自己单独维护的数据库,它们彼此之间不在同一个事务中,假如A执行成功了,B执行却失败了,而A的事务此时已经提交,无法回滚,那么最终就会导致两边数据不一致性的问题;尽管很早之前就有基于两阶段...
  • 8种方案,保证缓存和数据库的最终一致性

    千次阅读 多人点赞 2021-11-23 21:48:47
    由于对数据库以及缓存的整体操作,并不是原子性的,再加上读写并发,究竟什么样的方案可以保证数据库与缓存的一致性呢? 下面介绍8种方案,配合读写时序图,希望你能从其中了解到保证一致性的设计要点。
  • 提到分布式系统,就一定绕不开“一致性”,这次我们说说:最终一致性最终一致性是现在大部分高可用的分布式系统的核心思路。 估计有人对最终一致性不太熟,先来个简单介绍: 最终一致性指的是系统中的所有分散在...
  • 通俗易懂 强一致性、弱一致性、最终一致性、读写一致性、单调读、因果一致性 的区别与联系什么是一致性一致性的种类导致一致性出现的原因强一致性 与 弱一致性强一致性两个要求弱一致性强一致性和弱一致性举例顺序...
  • RabbitMQ消息最终一致性解决方案

    千次阅读 2019-09-29 10:50:38
    RabbitMQ消息最终一致性解决方案 随着分布式服务架构的流行与普及,原来在单体应用中执行的多个逻辑操作,现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩的能力,然而随之而来挑战...
  • 在足球比赛里,一个球员在一场比赛中进三个球,称之...一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行...
  • 最终一致性

    千次阅读 2018-06-09 21:23:46
    最终一致-构造一个世界范围级的可靠分布式系统需要在一致性和可用性之间做权衡Amzon S3,SimpleDB,EC2构建在亚马逊云计算的基础服务上,为其提供诸如构造万维网级计算平台和众多应用的资源。根植于这些基础服务上的...
  • 保证最终一致性的模式。

    千次阅读 2019-02-11 16:04:59
    在大规模、高并发服务化系统中,一个功能被拆分成多个具有单一功能的子功能,一个流程会有多个系统的多个单一功能的服务组合实现,如果使用两阶段提交协议和三阶段提交协议,则确实能解决系统间的一致性问题。...
  • 本文会从分布式事务产生背景开始,介绍常见分布式事务解决方案,最后会详细介绍基于消息中间件实现最终一致性的两种方案 文章目录分布式事务产生背景数据库水平拆分微服务拆分分布式事务解决方案TCCXA事务(2PC)最终...
  • 随着微服务的越来越多,一致性问题也越来越被重视。纠结是怎样才能ACID呢?...而本地消息表、可靠消息最终一致性方案、最大努力通知方案都是不错的解决方案。 目录 一致性问题 解决一致性问题的模式和思路 A...
  • 分布式消息最终一致性解决方案

    千次阅读 2019-03-22 13:59:41
    多个服务之间使用自己单独维护的数据库,它们彼此之间不在同一个事务中,假如A执行成功了,B执行却失败了,而A的事务此时已经提交,无法回滚,那么最终就会导致两边数据不一致性的问题;尽管很早之前就有基于两阶段...
  • 前言 在面过的几家大厂中,几乎每轮的面试官(没...答:分两部分来回答,第一部分先回答事务消息的实现流程,第二部分解释为什么它能保证数据的最终一致性。 事务消息的实现流程 [外链图片转存失败,源站可能有防盗链机
  • 分布式事务一个普遍且巨大的痛点是强一致和高可用,基于不同的一致性需求产生了不同的分布式事务解决方案,追求强一致的两阶段提交、追求最终一致性的柔性事务和事务消息等等。 ???????????? 我们综合对比下几种...
  • 一致性(Consistency) 是指多副本(Replications)问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 强一致性(Strict Consistency) 系统中的某个数据被成功更新后,后续任何对该数据的读取操作...
  • 介绍内容转载自:http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html https://blog.csdn.net/c289054531/article/details/15337575CAP原理中,有三个要素:一致性(Consistency)可用性(Availability...
  • 最近项目中有一个高并发的更新数据库单表单记录的功能,为了避免数据库压力,采取了更新该...RockectMQ事务消息提供了X/Open XA的分布式事务的功能,能实现分布式事务的最终一致性。 二、 X/Open XA规范是什么? X/OP
  • 对于分布式事务一般采用的都是最终一致性方案,而不是强一致性。而在使用最终一致性的方案时,一定要提到的一个概念是状态机。 什么是状态机?是一种特殊的组织代码的方式,用这种方式能够确保你的对象随时都知道...
  • RabbitMQ遵循了AMQP规范,用消息确认机制来保证:只要消息发送,就能确保被消费者消费来做到了消息最终一致性。而且开源,文档还异常丰富,貌似是实现分布式事务的良好载体 6.1 RabbitMQ消息确认机制 rabbitmq的...
  • 在分布式系统中会涉及到CAP原理,来保证数据的一致性, 1.什么是CAP: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理是说这三个要素最多只能同时满足两点,不可能...
  • 分布式事务之rabbitMQ最终一致性

    万次阅读 2019-05-26 22:56:56
    //本地消息服务一般抽离出来做成一个本地消息服务系统,因为其他服务也会用到,也要进行实现最终一致性进行存储本地消息 LocalMessageEntity localMessage = new LocalMessageEntity().setContext(context) ...
  • 最终一致性算法Gossip简介

    千次阅读 2017-04-14 16:03:17
    Rumor-Mongering模式有较小的网络、CPU负载,但必须为数据定义”最新“的边界,并且难以保证完全容错,对失败重启且超过”最新“期限的节点,无法保证最终一致性,或需要引入额外的机制处理不一致性。我们后续着重...
  • MQ消息最终一致性事务

    千次阅读 2019-01-12 10:54:27
    本文我们将学习到一种常见的柔性事务解决方案:消息一致性事务方案。 对于TCC型事务,跨系统的调用均是基于服务间的直接调用,即很大程度上是同步调用。基于TCC方案能够保证主子事务同时成功,同时失败。 但实际...
  • 什么是分布式事务 ...C (一致性):对某个指定的客户端来说,读操作能返回最新的写操作。 对于数据分布在不同节点上的数据来说,如果在某个节点更新了数据,那么在其他节点如果都能读取到这个最新的数...
  • 面试问题(如何保证分布式数据最终一致性

    万次阅读 多人点赞 2018-03-01 10:51:42
    保证分布式系统数据一致性的6种方案编者按:本文由「高可用架构后花园」群讨论整理而成。有人的地方,就有江湖有江湖的地方,就有纷争问题的起源在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用...
  • 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能 够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致 此方案是利用消息...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 599,862
精华内容 239,944
关键字:

最终一致性

友情链接: toyota_rav4.rar