vlambda博客
学习文章列表

CAP向左,CAP向右,ACID和BASE理论(一)

点击关注上方“知了小巷”,

设为“置顶或星标”,第一时间送达干货。

知了小巷
Java大数据与系统架构@好好学习,天天向上
93篇原创内容
Official Account

CAP概念和CAP定理

CAP概念

CAP理论是一个很好的思考框架,它对分布式系统的特性做了高度抽象,比如抽象成了一致性、可用性和分区容错性,并对特性间的冲突(CAP不可能三角)做了总结。

  • 一致性(Consistency)

数据在多个副本之间能够保持一致的特性(强一致性)

  • 可用性(Availability)

系统一直处于可用状态,能正常响应数据,但是不保证响应数据为最新数据

  • 分区容错性(Partition Tolerance)

分布式系统在遇到网络故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障

关于ZK到底提供了什么样的一致性保证:
https://zookeeper.apache.org/doc/r3.6.2/zookeeperProgrammers.html#ch_zkGuarantees

CAP向左,CAP向右,ACID和BASE理论(一)

Sequential Consistency(顺序一致性);一致性不保证正确性;准确一点,ZK的读操作是顺序一致性,ZK的写操作是线性一致性,整体(读+写)上是保证了顺序一致性;CAP中的C一般指线性一致性(强一致性、严格一致性、原子一致性;强一致是全局时钟下的顺序一致);etcd是标准的强一致性保证(etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. )


简单角色:一个多节点的分布式集群一个客户端

首先把多个节点组成的分布式系统当做一个节点间相互协作的整体,另外有一个客户端对这个整体中指定的一个或多个中的某一个(软负载)进行请求访问(读或写)。

一致性说的是客户端的每次读操作,不管访问哪个节点,要么读到的都是同一份最新的数据,要么读取失败。

我们可以把一致性看作是分布式系统对访问本系统的客户端的一种承诺:不管客户端访问的是哪个节点,要么返回的都是绝对一致(分布式系统内各个节点保持一致)的数据,要么返回读取失败。可以看到,一致性强调的不是数据完整,而是各节点间的数据一致(副本数据)

比如,2个节点的KV存储,原始的KV记录为“X = 1”

节点1  “X = 1”
节点2  “X = 1”

客户端

紧接着,客户端向节点1发送写请求“SET X = 2”

  • 如果节点1收到写请求后,只将节点1的X值更新为2,然后返回成功给客户端,这个时候(时间点)节点2的X值还是1(还没来得及同步或者同步失败),那么两个节点的X值是非一致性的。

  • 如果节点1收到写请求后,通过节点间的通讯(如RPC调用),同时将节点1节点2的X值都更新为2,然后再返回成功给客户端,那么在完成写请求后,两个节点的数据就是一致的了,之后,不管客户端访问哪个节点,读取到的都是同一份最新数据2(对于整个集群来说是最新的)。

一致性(大家都保持一致),在客户端看来,集群和单机在数据一致性上是一样的,或者说集群中任何一个节点都要代表整个集群(在对外的口径上,不能有两个或两个以上的声音)。

不过集群毕竟不是单机,当发生网络分区故障(两个或两个以上节点间通信故障) 的时候,有时不能仅仅因为节点间出现了通讯问题和节点中的数据出现不一致,就拒绝写入新数据,之后也不能在客户端查询数据时,就一直返回给客户端出错信息。

比如,用户可以选择向节点1节点2发起读操作,如果不管节点间的数据是否一致,只要节点服务器收到请求,就响应X的值,那么,2个节点的服务是满足可用性的。

最后的分区容错性,当节点间出现任意数量的消息丢失或高延迟的时候,系统仍然可以继续提供服务。也就是说,分布式系统在告诉访问本系统的客户端:不管我的内部出现什么样的数据同步问题(网络出现故障、某节点不工作等),我会一直运行,提供服务。这个指标,强调的是集群对网络分区故障的容错能力。(集群内部网络出现分区,即节点间相互沟通出现问题,比如访问或同步超时等

节点1节点2通信出问题的时候,如果系统仍能提供服务,那么,2个节点是满足分区容错性的。

因为分布式系统与单机系统不同,它涉及到多节点间的通讯和交互,节点间的分区故障是必然发生的,所以,在分布式系统中分区容错性是必须要考虑的

CAP定理(CAP theorem)

在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
一致性(Consistency) (等同于所有节点访问同一份最新的数据副本);
可用性(Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据);
分区容错性(Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。)

根据定理,分布式系统只能满足三项中的两项,而不可能满足全部三项,也被称为CAP不可能三角,只能在C、A、P 3个指标中选择2个。

如何使用CAP理论

我们都知道,只要有网络交互就一定会有延迟和数据丢失,而这种状况我们必须接受,还必须保证系统不能挂掉。所以就像上面提到的,节点间的分区故障是必然发生的。也就是说,分区容错性(P)是前提,是必须要保证的。现在就只剩下一致性(C)和可用性(A)可以选择了:要么选择一致性,保证数据绝对一致;要么选择可用性,保证服务可用。那么CPAP的含义是什么呢?

当选择了一致性(C)的时候,如果因为消息丢失、延迟过高发生了网络分区,部分节点无法保证特定信息是最新的,那么这个时候,当集群节点接收到来自客户端的写请求时,因为无法保证所有节点都是最新信息,所以系统将返回写失败错误,也就是说集群拒绝新数据写入。

当选择了可用性(A)的时候,系统将始终处理客户端的查询,返回特定信息,如果发生了网络分区,一些节点将无法返回最新的特定信息,它们将返回自己当前的相对新的信息。

大部分人对CAP理论有个误解,认为无论在什么情况下,分布式系统都只能在 C和A中选择1个。其实,在不存在网络分区的情况下,也就是分布式系统正常运行时(这也是系统在绝大部分时候所处的状态),就是说在不需要P时,C和A能够同时保证。只有当发生分区故障的时候,也就是说需要P时,才会在C和A之间做出选择。而且如果各节点数据不一致,影响到了系统运行或业务运行(也就是说会有负面的影响),推荐选择C,否则选A。

CA模型,在分布式系统中不存在。因为舍弃P,意味着舍弃分布式系统,就比如单机版关系型数据库MySQL,如果MySQL要考虑主备或集群部署时,它必须考虑 P。
CP模型,采用CP模型的分布式系统,一旦因为消息丢失、延迟过高发生了网络分区,就影响用户的体验和业务的可用性。因为为了防止数据不一致,集群将拒绝新数据的写入,典型的应用是ZooKeeper,Etcd和HBase。
AP模型,采用AP模型的分布式系统,实现了服务的高可用。用户访问系统的时候,都能得到响应数据,不会出现响应错误,但当出现分区故障时,相同的读操作,访问不同的节点,得到响应数据可能不一样。典型应用就比如Cassandra和DynamoDB。

猜你喜欢
















点一下,代码无 Bug