浅谈分布式CAP定理

互联网发展到现在,由于数据量大、操作并发高等问题,大部分网站项目都采用分布式的架构。而分布式系统最大的特点数据分散,在不同网络节点在某些时刻(数据未同步完,数据丢失),数据会不一致。

在2000年,Eric Brewer教授在PODC的研讨会上提出了一个猜想:一致性、可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个!

在2002年,Lynch证明其猜想,上升为定理。被这就是大家所认知的CAP定理。

CAP是所有分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。

CAP定义

所谓的CAP就是分布式系统的三个特性:

  • Consistency,一致性。所有分布式节点的数据是否一致。
  • Availability,可用性。在部分节点有问题的情况(数据不一致、节点故障)下,是否能继续响应服务(可用)。
  • Partition tolerance,分区容错性。允许在节点(分区)数据不一致的情况。

深入理解

有A、B、C三个分布式数据库。

当A、B、C的数据是完全相同,那么就符合定理中的Consistency(一致性)。

假如A的数据与B的数据不相同,但是整体的服务(包含A、B、C的整体)没有宕机,依然可以对外系统服务,那么就符合定理中的Availability(可用性)。

分布式数据库是没有办法百分百时刻保持各个节点数据一致的。假设一个用户再A库上更新了一条记录,在更新完这一刻,A与B、C库的数据是不一致的。这种情况在分布式数据库上是必然存在的。这就是Partition tolerance(分区容错性)

当数据不一致的时候,必定是满足分区容错性,如果不满足,那么这个就不是一个可靠的分布式系统。

然而在数据不一致的情况下,系统要么选择优先保持数据一致性,这样的话。系统首先要做的是数据的同步操作,此时需要暂停系统的响应。这就是满足CP。

若系统优先选择可用性,那么在数据不一致的情况下,会在第一时间放弃一致性,让整体系统依然能运转工作。这就是AP。

所以,分布式系统在通常情况下,要不就满足CP,要不就满足AP。

那么有没有满足CA的呢?有,当分布式节点为1的时候,不存在P,自然就会满足CA了。

例子

上面说到,分区容错性是分布式系统中必定要满足的,需要权衡的是系统的一致性与可用性。那么常见的分布式系统是基于怎样的权衡设计的。

  • Zookeeper
    保证CP。当主节点故障的时候,Zookeeper会重新选主。此时Zookeeper是不可用的,需要等待选主结束才能重新提供注册服务。显然,Zookeeper在节点故障的时候,并没有满足可用性的特性。在网络情况复杂的生产环境下,这样的的情况出现的概率也是有的。一旦出现,如果依赖Zookeeper的部分会卡顿,在大型系统上,很容易引起系统的雪崩。这也是大型项目不选Zookeeper当注册中心的原因。
  • Eureka
    保证AP。在Eureka中,各个节点是平等的,它们相互注册。挂掉几个节点依然可以提供注册服务的(可以配置成挂掉的比例),如果连接的Eureka发现不可用,会自动切换到其他可用的几点上。另外,当一个服务尝试连接Eureka发现不可用的时候,切换到另外一个Eureka服务上,有可能由于故障节点未来得及同步最新配置,所以这个服务读取的数据可能不是最新的。所以当不要求强一致性的情况下,Eureka作为注册中心更为可靠。
  • Git
    其实Git也是也是分布式数据库。它保证的是CP。很容易猜想到,云端的Git仓库于本地仓库必定是要保证数据的一致性的,如果不一致会先让数据一致再工作。当你修改完本地代码,想push代码到Git仓库上时,假如云端的HEAD与本地的HEAD不一致的时候,会先同步云端的HEAD到本地HEAD,再把本地的HEAD同步到云端。最终保证数据的一致性。

更多技术文章、精彩干货,请关注
个人博客:zackku.com
微信公众号:Zack说码

posted on 2018-12-07 09:41 公众号_Zack说码 阅读(...) 评论(...) 编辑 收藏

导航

公告