精华内容
下载资源
问答
  • 的区别与联系什么是一致性一致性的种类导致一致性出现的原因强一致性 与 弱一致性强一致性两个要求弱一致性强一致性和弱一致性举例顺序一致性最终一致性最终一致性的种类 什么是一致性 在分布式系统中,一致性...

    什么是一致性

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

    一致性的种类

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

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

    导致一致性出现的原因

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

    强一致性 与 弱一致性

    数据一致性的种类

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

    强一致性两个要求

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

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

    弱一致性

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

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

    强一致性和弱一致性举例

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

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

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

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

    顺序一致性

    两个要求:

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

    顺序一致性参考

    最终一致性

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

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

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

    最终一致性的种类

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

    • 因果一致性(Casual Consistency)。如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将返回更新后的值,且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问,遵守一般的最终一致性规则。
    • “读己之所写(read-your-writes)”一致性。当进程A自己更新一个数据项之后,它总是访问到更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例。
    • 会话(Session)一致性。这是上一个模型的实用版本,它把访问存储系统的进程放到会话的上下文中。只要会话还存在,系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统的保证不会延续到新的会话。
    • 单调(Monotonic)读一致性。如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值。
    • 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性,就非常难以编程了。
    展开全文
  • 1. 主从同步 redis支持master-slave模式,一主多...redis实现最终会一致性,具体选择强一致性还是弱一致性,取决于业务场景。 redis 主从同步有两种方式(或者所两个阶段):全同步部分同步。 主从刚刚连接...

    1. 主从同步

    redis支持master-slave模式,一主多从,redis server可以设置另外多个redis server为slave,从机同步主机的数据。配置后,读写分离,主机负责读写服务,从机只负责读。减轻主机的压力。redis实现的是最终会一致性,具体选择强一致性还是弱一致性,取决于业务场景。
    redis 主从同步有两种方式(或者所两个阶段):全同步和部分同步。

    主从刚刚连接的时候,进行全同步;全同步结束后,进行部分同步。当然,如果有需要,slave 在任何时候都可以发起全同步。redis 策略是,无论如何,首先会尝试进行部分同步,如不成功,要求从机进行全同步,并启动 BGSAVE……BGSAVE 结束后,传输 RDB 文件;如果成功,允许从机进行部分同步,并传输积压空间中的数据。简单来说,主从同步就是 RDB 文件的上传下载;主机有小部分的数据修改,就把修改记录传播给每个从机。

     

    2、redis集群

    主从模式存在的问题是,master宕机之后,从机只能读,不可写,不能保证高可用。redis集群技术是构建高性能网站架构的重要手段,试想在网站承受高并发访问压力的同时,还需要从海量数据中查询出满足条件的数据,并快速响应,我们必然想到的是将数据进行切片,把数据根据某种规则放入多个不同的服务器节点,来降低单节点服务器的压力。

    Redis Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。节点之间使用gossip协议传播信息以及发现新节点。

    Redis 集群是一个分布式(distributed)、容错(fault-tolerant)的 Redis 实现,集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集(subset)。

    Redis 集群中不存在中心(central)节点或者代理(proxy)节点,集群的其中一个主要设计目标是达到线性可扩展性(linear scalability)。

    Redis 集群为了保证一致性(consistency)而牺牲了一部分容错性:系统会在保证对网络断线(net split)和节点失效(node failure)具有有限(limited)抵抗力的前提下,尽可能地保持数据的一致性。

     

    3、原理

    3.1、 一致性

    filesnapshot:默认redis是会以快照的形式将数据持久化到磁盘,在配置文件中的格式是:save N M表示在N秒之内,redis至少发生M次修改则redis抓快照到磁盘。

    工作原理:当redis需要做持久化时,redis会fork一个子进程;子进程将数据写到磁盘上一个临时RDB文件中;当子进程完成写临时文件后,将原来的RDB替换掉,这样的好处就是可以copy-on-write。

    Append-only:filesnapshotting方法在redis异常死掉时, 最近的数据会丢失(丢失数据的多少视你save策略的配置),所以这是它最大的缺点,当业务量很大时,丢失的数据是很多的。Append-only方法可 以做到全部数据不丢失,但redis的性能就要差些。AOF就可以做到全程持久化,只需要在配置文件中开启(默认是no),appendonly yes开启AOF之后,redis每执行一个修改数据的命令,都会把它添加到aof文件中,当redis重启时,将会读取AOF文件进行“重放”以恢复到 redis关闭前的最后时刻。

    AOF文件刷新的方式,有三种,参考配置参数appendfsync :

    • appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件,非常非常慢,但也非常安全;
    • appendfsync everysec每秒钟都调用fsync刷新到AOF文件,很快,但可能会丢失一秒以内的数据;
    • appendfsync no依靠OS进行刷新,redis不主动刷新AOF,这样最快,但安全性就差。默认并推荐每秒刷新,这样在速度和安全上都做到了兼顾。

    Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。

    Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求。

    Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据。

    为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成。即便如此,系统的伸缩性还是得到了很大的提高。

    Master可以将数据保存操作交给Slaves完成,从而避免了在Master中要有独立的进程来完成此操作。
    Redis在master是非阻塞模式,也就是说在slave执行数据同步的时候,master是可以接受客户端的请求的,并不影响同步数据的一致性,然而在slave端是阻塞模式的,slave在同步master数据时,并不能够响应客户端的查询。

    3.2 Replication的工作原理

    (1)Slave服务器连接到Master服务器。
    (2)Slave服务器发送SYCN命令。
    (3)Master服务器备份数据库到.rdb文件。
    (4)Master服务器把.rdb文件传输给Slave服务器。
    (5)Slave服务器把.rdb文件数据导入到数据库中。

    在Slave启动并连接到Master之后,它将主动发送一个SYNC命令。此后Master将启动后台存盘进程,同时收集所有接收到的用于修改数据集 的命令,在后台进程执行完毕后,Master将传送整个数据库文件到Slave,以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其 存盘并加载到内存中。此后,Master继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,Slave将在本次执行这些数据修改命令,从而达到最终的数据同步。如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。

    3.3 一致性哈希

    集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点,这里我们需要一个规则或者算法,通常的做法是获取 key 的哈希值,然后根据节点数来求模,但这种做法有其明显的弊端,当我们需要增加或减少一个节点时,会造成大量的 key 无法命中,这种比例是相当高的,所以就有人提出了一致性哈希的概念。
    一致性哈希有四个重要特征:

    • 均衡性:也有人把它定义为平衡性,是指哈希的结果能够尽可能分布到所有的节点中去,这样可以有效的利用每个节点上的资源。
    • 单调性:对于单调性有很多翻译让我非常的不解,而我想要的是当节点数量变化时哈希的结果应尽可能的保护已分配的内容不会被重新分派到新的节点。
    • 分散性和负载:这两个其实是差不多的意思,就是要求一致性哈希算法对 key 哈希应尽可能的避免重复。

    Redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

    使用哈希槽的好处就在于可以方便的添加或移除节点。

    1. 当需要增加节点时,只需要把其他节点的某些哈希槽挪到新节点就可以了;
    2. 当需要移除节点时,只需要把移除节点上的哈希槽挪到其他节点就行了;
    3. 当设置了主从关系后,slave 在第一次连接或者重新连接 master 时,slave 都会发送一条同步指令给 master;
    4. master 接到指令后,开始启动后台保存进程保存数据,接着收集所有的数据修改指令。后台保存完了,master 就把这份数据发送给 slave,slave 先把数据保存到磁盘,然后把它加载到内存中,master 接着就把收集的数据修改指令一行一行的发给 slave,slave 接收到之后重新执行该指令,这样就实现了数据同步。
    5. slave 在与 master 失去联系后,自动的重新连接。如果 master 收到了多个 slave 的同步请求,它会执行单个后台保存来为所有的 slave 服务。

    3.4 节点失效检测

    以下是节点失效检查的实现方法:

    1. 当一个节点向另一个节点发送 PING 命令,但是目标节点未能在给定的时限内返回 PING 命令的回复时,那么发送命令的节点会将目标节点标记为PFAIL (possible failure,可能已失效)。
    2. 等待 PING 命令回复的时限称为“节点超时时限(node timeout)”,是一个节点选项(node-wise setting)。
    3. 每次当节点对其他节点发送 PING 命令的时候,它都会随机地广播三个它所知道的节点的信息,这些信息里面的其中一项就是说明节点是否已经被标记为 PFAIL 或者 FAIL 。
    4. 当节点接收到其他节点发来的信息时,它会记下那些被其他节点标记为失效的节点。这称为失效报告(failure report)。
    5. 如果节点已经将某个节点标记为 PFAIL ,并且根据节点所收到的失效报告显式,集群中的大部分其他主节点也认为那个节点进入了失效状态,那么节点会将那个失效节点的状态标记为 FAIL 。
    6. 一旦某个节点被标记为 FAIL ,关于这个节点已失效的信息就会被广播到整个集群,所有接收到这条信息的节点都会将失效节点标记为 FAIL 。

    简单来说,一个节点要将另一个节点标记为失效,必须先询问其他节点的意见,并且得到大部分主节点的同意才行。因为过期的失效报告会被移除,所以主节点要将某个节点标记为 FAIL 的话,必须以最近接收到的失效报告作为根据。
    在以下两种情况中,节点的 FAIL 状态会被移除:

    1. 如果被标记为 FAIL 的是从节点,那么当这个节点重新上线时, FAIL 标记就会被移除。保持(retaning)从节点的 FAIL 状态是没有意义的,因为它不处理任何槽,一个从节点是否处于 FAIL 状态,决定了这个从节点在有需要时能否被提升为主节点。
    2. 如果一个主节点被打上 FAIL 标记之后,经过了节点超时时限的四倍时间,再加上十秒钟之后,针对这个主节点的槽的故障转移操作仍未完成,并且这个主节点已经重新上线的话,那么移除对这个节点的 FAIL 标记。
    3. 在第二种情况中,如果故障转移未能顺利完成,并且主节点重新上线,那么集群就继续使用原来的主节点,从而免去管理员介入的必要。

    3.5 从节点选举

    一旦某个主节点进入 FAIL 状态,如果这个主节点有一个或多个从节点存在,那么其中一个从节点会被升级为新的主节点,而其他从节点则会开始对这个新的主节点进行复制。
    新的主节点由已下线主节点属下的所有从节点中自行选举产生,以下是选举的条件:

    1. 这个节点是已下线主节点的从节点。
    2. 已下线主节点负责处理的槽数量非空。
    3. 从节点的数据被认为是可靠的,也即是,主从节点之间的复制连接(replication link)的断线时长不能超过节点超时时限(node timeout)乘以REDIS_CLUSTER_SLAVE_VALIDITY_MULT 常量得出的积。

    如果一个从节点满足了以上的所有条件,那么这个从节点将向集群中的其他主节点发送授权请求,询问它们,是否允许自己(从节点)升级为新的主节点。
    如果发送授权请求的从节点满足以下属性,那么主节点将向从节点返回 FAILOVER_AUTH_GRANTED 授权,同意从节点的升级要求:

    1. 发送授权请求的是一个从节点,并且它所属的主节点处于 FAIL 状态。
    2. 在已下线主节点的所有从节点中,这个从节点的节点 ID 在排序中是最小的。
    3. 从节点处于正常的运行状态:它没有被标记为 FAIL 状态,也没有被标记为 PFAIL 状态。

    一旦某个从节点在给定的时限内得到大部分主节点的授权,它就会开始执行以下故障转移操作:

    1. 通过 PONG 数据包(packet)告知其他节点,这个节点现在是主节点了。
    2. 通过 PONG 数据包告知其他节点,这个节点是一个已升级的从节点(promoted slave)。
    3. 接管(claiming)所有由已下线主节点负责处理的哈希槽。
    4. 显式地向所有节点广播一个 PONG 数据包,加速其他节点识别这个节点的进度,而不是等待定时的 PING / PONG 数据包。
    5. 所有其他节点都会根据新的主节点对配置进行相应的更新,特别地:
      a. 所有被新的主节点接管的槽会被更新。
      b. 已下线主节点的所有从节点会察觉到 PROMOTED 标志,并开始对新的主节点进行复制。
      c.如果已下线的主节点重新回到上线状态,那么它会察觉到 PROMOTED 标志,并将自身调整为现任主节点的从节点。

    在集群的生命周期中,如果一个带有 PROMOTED 标识的主节点因为某些原因转变成了从节点,那么该节点将丢失它所带有的 PROMOTED 标识。

    划重点:为什么不选哨兵,而选择 redis cluster 。关于技术选型的思路可以参见:https://juejin.im/post/5a54a6fbf265da3e3f4c9048

    展开全文
  • 在面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要详情分布式一致性:强一致性最终一致性、ACID、CAP等理论。分布式一致性的背景随着分布式事务的出现,传统...

    在面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要详情分布式一致性:强一致性、最终一致性、ACID、CAP等理论。

    分布式一致性的背景

    随着分布式事务的出现,传统的单机事务模型(ACID)已经无法胜任,尤其是对于一个高访问量、高并发的互联网分布式系统来说。

    假如我们要求严格一致性,很可能就需要牺牲掉系统的可用性,反之亦然。

    如何构建一个兼顾可用性和一致性的分布式系统成为了无数Java工程师讨论的难题。

    b1f9c43beaa2896c8bde955f4106b810.png

    数据一致性的由来

    一致性(Consistency)一直是分布式系统里一个很重要的话题。

    在存储系统中,为了避免数据丢失,我们都会对数据进行持久化。

    c484912a83454aee7283aceccc8653b3.png

    对数据进行持久化可以避免宕机带来的数据丢失问题,但是不能处理单机永久性故障的问题。存储系统作为基础设备,在单机上持久化是远远不够的,我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。

    9396846442f678fef4e3b5b89380053e.png

    一旦数据被复制到多个节点,那么就产生了一致性的问题。

    0a9fb364e76b4bb4a4f848031c35e7da.png

    分布式数据一致性的级别

    1、强一致性

    是最强的一致性模型,要求任何读取操作都能读取到最新的值,换句话说,要求任何写入操作立即同步给所有进程。

    2、弱一致性

    这种一致性级别束缚了系统在写入成功后,不承诺立就可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比方秒级别)后,数据能够达到一致状态。

    3、最终一致性

    最终一致性是弱一致性的一个特例,系统会保证在肯定时间内,能够达到一个数据一致的状态。

    这里之所以将最终一致性单独提出来,是由于它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型。

    一致性相关的理论

    关系式数据库ACID

    ACID是数据库(MySQL)事务正确执行所必需满足的四个特性的首字母缩写。

    1.Atomicity(原子性)

    一个事务的所有操作,要么一律完成,要么一律不完成。

    所谓事务,是指由一系列数据操作所组成的完整逻辑过程。比方银行转账事务由两个操作组成:从源账户扣除金额,以及向目标账户添加金额。

    2.Consistency(一致性)

    指事务开始之前和事务结束之后,数据的完整性束缚没有被破坏。

    包含两层含义:

    a)数据库机制层面,事务执行前后,数据能符合设置的束缚,如唯一束缚、外键束缚;

    b)业务层面,由应用开发人员保证业务一致性。还是以银行转账为例,A、B两个账号,转账之前和之后,A、B两个账号余额总额必需一致。

    3.Isolation(隔离性)

    数据库能够防止因为多个并发事务交叉执行而导致数据的不一致。

    4.Durability(持久性)

    指事务结束后,对数据的修改是永久的,不会回滚到之前的状态。

    CAP理论

    在分布式系统中,也有相似数据库ACID的特性,那就是CAP,他们分别是:

    1.Consistency 一致性

    强调进群节点中数据一致。在分布式中一致性又包括强一致性和弱一致性,强一致性就是指在任何时刻任何节点看到的数据都是一样的;

    弱一致性一般实现是最终一致性,即刚开始可能存在差异,但随着时间的推移,最终数据保持一致。

    2.Availability 可用性

    强调集群在任何时间内都正常使用

    3.Partition Tolerance 分区容错性

    即便某一部分集群坏掉,另一部分仍能正常工作。

    这三个特性只能满足其中两个,牺牲另一个。大部分系统也都是如此:

    一般来说分布式集群都会保证P优先,即集群部分节点坏死不影响整个集群的使用,而后再去追求C和A。由于假如放弃P——分区可用性,那不如就直接使用多个传统数据库了。事实上,很多微服务分库分表就是这个道理。

    假如追求强一致性,那么势必会导致可用性下降。比方在Master-Slave的场景中,Master负责数据写入,而后分发给各个节点,所有节点都写入成功,才算写入,这样保证了强一致性,但是推迟也会随之添加,导致可用性降低。

    因而在可用性和一致性之间,就出现了各种处理方案,如时序一致性、最终一致性等等。

    BASE理论

    BASE理论是对CAP理论的延伸,核心思想是即便无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

    BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。

    1.基本可用(Basically Available)

    基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

    电商大促时,为了应对访问量激增,部分客户可能会被引导到降级页面,服务层也可能只提供降级服务,这就是损失部分可用性的表现。

    2.软状态( Soft State)

    软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。

    分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的表现。mysql replication的异步复制也是一种表现。

    3.最终一致性( Eventual Consistency)

    最终一致性是指系统中的所有数据副本经过肯定时间后,最终能够达到一致的状态。

    弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

    BASE和ACID代表两种截然相反的设计理念,ACID注重一致性,是传统关系型数据库(MySQL)的设计思路,BASE关注高可用性。

    当今大规模、跨数据中心的分布式系统(如云计算)大多同时采用这两种设计理念,并在两者之间寻求平衡。

    以上就是分布式一致性理论的详情,更多分布式架构设计:Redis缓存、Dubbo、Kafka、秒杀专题,请参考:阿里架构师进阶23期精讲:Redis、Kafka、Dubbo、Docker等

    aa4588eea2e9dd40bab792f25ddb8b6a.png

    觉得有用请点赞支持,欢迎留言或者进我的QQ群179961551交流,本群专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、讨论。

    展开全文
  • 在面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要介绍分布式一致性:强一致性最终一致性、ACID、CAP等理论。分布式一致性的背景随着分布式事务的出现,传统...

    在面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要介绍分布式一致性:强一致性、最终一致性、ACID、CAP等理论。

    分布式一致性的背景

    随着分布式事务的出现,传统的单机事务模型(ACID)已经无法胜任,尤其是对于一个高访问量、高并发的互联网分布式系统来说。

    如果我们要求严格一致性,很可能就需要牺牲掉系统的可用性,反之亦然。

    如何构建一个兼顾可用性和一致性的分布式系统成为了无数Java工程师探讨的难题。

    d301d59cd884

    数据一致性的由来

    一致性(Consistency)一直是分布式系统里一个很重要的话题。

    在存储系统中,为了避免数据丢失,我们都会对数据进行持久化。

    d301d59cd884

    对数据进行持久化可以避免宕机带来的数据丢失问题,但是不能解决单机永久性故障的问题。存储系统作为基础设施,在单机上持久化是远远不够的,我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。

    d301d59cd884

    一旦数据被复制到多个节点,那么就产生了一致性的问题。

    d301d59cd884

    分布式数据一致性的级别

    1、强一致性

    是最强的一致性模型,要求任何读取操作都能读取到最新的值,换句话说,要求任何写入操作立即同步给所有进程。

    2、弱一致性

    这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态。

    3、最终一致性

    最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。

    这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型。

    一致性相关的理论

    关系式数据库ACID

    ACID是数据库(MySQL)事务正确执行所必须满足的四个特性的首字母缩写。

    1.Atomicity(原子性)

    一个事务的所有操作,要么全部完成,要么全部不完成。

    所谓事务,是指由一系列数据操作所组成的完整逻辑过程。比如银行转账事务由两个操作组成:从源账户扣除金额,以及向目标账户增加金额。

    2.Consistency(一致性)

    指事务开始之前和事务结束之后,数据的完整性约束没有被破坏。

    包含两层含义:

    a)数据库机制层面,事务执行前后,数据能符合设置的约束,如唯一约束、外键约束;

    b)业务层面,由应用开发人员保证业务一致性。还是以银行转账为例,A、B两个账号,转账之前和之后,A、B两个账号余额总额必须一致。

    3.Isolation(隔离性)

    数据库能够防止由于多个并发事务交叉执行而导致数据的不一致。

    4.Durability(持久性)

    指事务结束后,对数据的修改是永久的,不会回滚到之前的状态。

    CAP理论

    在分布式系统中,也有类似数据库ACID的特性,那就是CAP,他们分别是:

    1.Consistency 一致性

    强调进群节点中数据一致。在分布式中一致性又包括强一致性和弱一致性,强一致性就是指在任何时刻任何节点看到的数据都是一样的;

    弱一致性一般实现是最终一致性,即刚开始可能存在差异,但随着时间的推移,最终数据保持一致。

    2.Availability 可用性

    强调集群在任何时间内都正常使用

    3.Partition Tolerance 分区容错性

    即使某一部分集群坏掉,另一部分仍能正常工作。

    这三个特性只能满足其中两个,牺牲另一个。大部分系统也都是如此:

    一般来说分布式集群都会保证P优先,即集群部分节点坏死不影响整个集群的使用,然后再去追求C和A。因为如果放弃P——分区可用性,那不如就直接使用多个传统数据库了。事实上,很多微服务分库分表就是这个道理。

    如果追求强一致性,那么势必会导致可用性下降。比如在Master-Slave的场景中,Master负责数据写入,然后分发给各个节点,所有节点都写入成功,才算写入,这样保证了强一致性,但是延迟也会随之增加,导致可用性降低。

    因此在可用性和一致性之间,就出现了各种解决方案,如时序一致性、最终一致性等等。

    BASE理论

    BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

    BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。

    1.基本可用(Basically Available)

    基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

    电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务,这就是损失部分可用性的体现。

    2.软状态( Soft State)

    软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。

    分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

    3.最终一致性( Eventual Consistency)

    最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

    弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

    BASE和ACID代表两种截然相反的设计理念,ACID注重一致性,是传统关系型数据库(MySQL)的设计思路,BASE关注高可用性。

    当今大规模、跨数据中心的分布式系统(如云计算)大多同时采用这两种设计理念,并在两者之间寻求平衡。

    以上就是分布式一致性理论的介绍,更多分布式架构设计:Redis缓存、Dubbo、Kafka、秒杀专题,请参考:阿里架构师进阶23期精讲:Redis、Kafka、Dubbo、Docker等

    d301d59cd884

    觉得不错请点赞支持,欢迎留言或进我的个人群179961551领取【架构资料专题目合集90期】、【BATJTMD大厂JAVA面试真题1000+】,本群专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、探讨。

    展开全文
  • 包含两种含义:缓存DB数据一致缓存中没有数据(或者说:不会去读缓存中的老版本数据)首先我们来分析一下,既然已经实现了“最终一致性”,那它强一致性的区别是什么呢?没错,就是“时间差”,所以:“最终...
  • Spring Cloud Eureka 和 Consul的区别 最大的区别是Eureka保证AP, Consul为CP。...Eureka保证高可用(A)和最终一致性: 服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
  • Redismemcached的区别

    2020-05-05 01:59:40
    1、强一致性:任何时刻所有用户查询到都是最新数据。(关系型数据库更新操作) 最终一致性:某一时刻不同用户或进程查到数据可能不同,但是最终更新成功数据都能查到。(主流NoSQL是这种) NoSQL:基于...
  • 1. 分类 区块链共识算法可以根据其容错类型、部署方式、一致性程度、选主策略等多个维度进行分类。 维度 ... 该维度所有分类 ... 公有链共识、联盟链共识私有链... 强一致性共识、弱(最终) ...
  • 摘要 在分布式架构中往往伴随CAP理论。因为分布式架构,不再使用传统单机架构,多机为了提供可靠服务所以需要冗余数据因而会存在分区容忍...不强求数据的强一致性,达成数据的最终一致性。 1 Eureka AP eurek
  • 9、consul与Eureka的区别

    千次阅读 2020-03-23 17:23:11
    (1)一致性 Consul强一致性(CP) ...因为Consulraft协议要求必须过半数节点都写入...Eureka保证高可用和最终一致性(AP) 1、服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否 repl...
  • Cassandra不会使用回滚和锁机制来实现关系型数据ACID事务,相比较于提供原子性,隔离性和持久化,Cassandra提供最终(可调节)一致性,让用户决定为每个事务提供强一致性或者最终一致性。作为非关系型数据库,...
  • Spring Cloud Eureka Consul使用对比

    万次阅读 2018-08-06 14:25:00
    最大的区别是Eureka保证AP, Consul为CP。 Consul强一致性(C)带来的是: ... Leader挂掉时,重新选举期间整个consul不可用。...Eureka保证高可用(A)和最终一致性: 服务注册相对要快,因为不需要等注册信息replica...
  • 强一致性 弱一致性 最终一致性(2阶段提交,3阶段提交) redis内部原理 zookeeper如何实现数据同步的 redismemoryCache的区别 zookeeper内部原理(各种一致性算法) zookeeper的一致性是怎么实现的? ...
  • 通过模拟人群内部信任和决策机制,针对多用户频谱协作感知一致性问题,...理论分析与仿真结果表明,新算法在准确性和安全性上均优于传统合作频谱感知算法,能显著提高频谱感知准确率,同时兼具较强的防攻击能力。
  • 4.1.1 并发访问数据一致性 97 4.1.2 事务隔离级别 98 4.1.3 Oracle支持隔离级别 99 4.2 Oracle单实例并发控制机制 100 4.2.1 Lock 100 4.2.2 数据记录行级锁 101 4.2.3 Latch 105 4.2.4 ...
  • 最大的区别是Eureka保证AP, Consul为CP。 Consul强一致性(C)带来的是: ...Leader挂掉时,重新选举期间整个consul不可用。...Eureka保证高可用(A)和最终一致性: 服务注册相对要快,因为不需要等注册信息replicat...
  • Consul(代替Eureka) ...Eureka保证高可用和最终一致性(AP) 服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功 当数据出现不一致时,虽然A, B上
  • Consul与euerka对比

    2018-10-11 12:31:34
    最大的区别是Eureka保证AP, Consul为CP。 Consul强一致性(C)带来的是: ... Leader挂掉时,重新选举期间整个consul不可用。...Eureka保证高可用(A)和最终一致性: 服务注册相对要快,因为不需要等注册信息replica...
  • 先知道几个名词 C强一致性 A可用性 P分区容忍性 Eureka: 保证了AP,可以保证最终一致性 保证了可用性,实现最终一致性。Eureka各个节点都是平等,几个节点挂掉不会影响正常节点工作,剩余节点依然可以提供...
  • Eureka VS Consul VS Zookeeper

    千次阅读 2018-12-20 18:42:13
    最大的区别是Eureka保证AP, Consul为CP。 Consul强一致性(C)带来的是: ... 2 Leader挂掉时,重新选举期间整个consul不可用。...Eureka保证高可用(A)和最终一致性:  1 服务注册相对要快,因为...
  • Consul arch(四) gossip

    2020-11-20 17:07:19
    注意 raft 的区别,consul 使用 raft 管理 consul servers 之间的状态同步问题,是个强一致性协议;而 gossip 则实现了 consul cluster 中所有节点发现、失效探测等状态同步问题。 注意,既然 gossip 是最终一致性...
  • 针对极化码盲识别问题,首先证明了能表征实际极化码码长、码率关系定理1...仿真结果表明,3个定理结论与仿真结果一致,且算法具有较强的容错,在信噪比为6.5 dB、码长为1 024条件下,参数识别率能够达到98%以上。
  • 大数据基础

    2017-11-08 23:06:00
    5、一致性模型:、弱、最终一致。 6、备份机制:法7,Leader-Follower模式 7、共识协议:一致性协议。Paxos或者Raft 8、算法与数据结构 9、LSM:学习B+树的区别和优势 10、压缩算法:主流压缩算法...
  • Redis(1)

    2019-10-29 17:09:34
    C:强一致性 A:高可用性 P:分区容忍性 BASE BA:基本可用 S: E:最终一致性 RedisMemcache的区别 1)从实现来看: Redis:单线程 Memcache:多线程(区别:多线程中存在cpu在线程上下文切换,时间都耗费在...
  • Spring Cloud面试题

    2019-09-23 10:26:25
    C:强一致性 A:高可用性 P:分区容错性 1.ZooKeeper保证是CP,Eureka保证是AP ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用 Eureka各个节点是平等关系,只要有一台Eureka就可以保证...

空空如也

空空如也

1 2 3 4 5
收藏数 86
精华内容 34
关键字:

强一致性和最终一致性的区别