vlambda博客
学习文章列表

【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论


【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论Lvshen的技术小屋推荐搜索
设计模式
Java后端面试
干净的代码
线程池
IDEA技巧
Spring


CAP定理

CAP定理又叫布鲁尔定理,这个定理告诉我们在一个分布式系统中,不可能同时满足下面三点:

  • 一致性( Consistency) (等同于所有节点访问同一份最新的数据副本)
  • 可用性( Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
  • 分区容错性( Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。)

这个定理认为分布式系统最多只能满足上面两点。

【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论

起源

这个定理起源于加州大学柏克莱分校(University of California, Berkeley)的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会(PODC)上提出的一个猜想。在2002年,麻省理工学院(MIT)的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明,使之成为一个定理。

吉尔伯特和林奇证明的CAP定理比布鲁尔设想的某种程度上更加狭义。定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。

——来源:维基百科

Partition tolerance

Partition tolerance又叫分区容错,那我们来了解下什么是分区。一般分布式系统可能会将服务器部署在不同的地区。比如淘宝系统,可能子系统1部署在广州,子系统2部署在新疆。那么这两个地区就是两个区。系统1与系统2之间可能存在通信问题。所以在系统设计时需要考虑这种情况。

【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论

Consistency

Consistency又叫一致性,这个大家应该有所了解。比如我们经常会遇到这些问题:如何保证缓存与数据库数据的一致性,如何保证中间件master节点与slave节点数据的一致性等等。

举个具体的例子,当前系统中某条数据是A1,如果用户将系统中的这条数据将A1修改成A2,那么用户接下来读取这条数据就是A2。这样就保证了数据读写的一致性。

但是如果这个系统是主从系统,系统1负责写,系统2负责读。当用户将A2写入系统1,这是系统1由于某些原因没有将更新的数据同步到系统2,那么用户还是读到了之前的数据A1。这里就导致了数据读写不一致问题。

Availability

Availability中文名可用性,这个很好理解。如果你要部署Redis,如果是单机部署,当这台ES挂掉,那么会导致系统不可用,这时推荐分布式集群部署。部署结构图如下:

【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论

如上图,当redis-master挂掉,会从slave1、slave2、slave3中选举一台成为master从而保证redis集群正常运行。这个过程对用户来说是不可感知的。集群保证了系统的可用性。

关于可用性与一致性

我们无法同时保证系统的可用性与一致性。这里简单的论证一下:如果要保证一致性,就需要在对写数据时对系统上锁,或者使用单机系统。那么在锁没有释放之前用户无法再次写数据,对于单机系统。系统挂掉也会导致系统不可用;如果要保证可用性,那么就要使用集群,就需要有系统之间的同步,也有可能导致同步不成功,从而导致系统的数据不一致性。

所以说,在实际场景下面,我们要侧重,要么保证可用性。要么保证一致性。

当然保证了系统可用性并不是说不要一致性了。我们最终还是要保证系统的最终一致性。

BASE理论

BASE理论主要包含下面几个内容:

  • Basically Available(基本可用)
  • Soft state(软状态)
  • Eventually consistent(最终一致性)

在CAP定理中,我们知道3者只能选其2。对于系统来说,分区容错性是必须要满足的,你不可能在两个分区中通信经常出现问题,这对于系统来说是灾难性的。

那么我们主要就是要在可用性与一致性之间取舍。就是AP与CP的问题了。

Basically Available

对于基本可用,我们举个例子,在秒杀系统中,为了保证系统能抗住并发压力,并不是所有用户都能访问到真正的服务器的,大部分访问者可能会被引导到其他页面(或服务器)。而界面上可能显示的就是:商品已经售罄,谢谢惠顾。

这里我们至少保证了系统可用,如果所有用户都能访问到系统,那么最终导致系统崩溃。

Soft state

在软状态中,我们允许系统的数据存在中间状态,并且这种状态不会影响整体的可用性。

举个例子,Redis主从同步中,同步不及时,可能主数据和从数据不一致。如果我们的业务允许不一致,那么这个不一致的状态就是软状态。

也就是说,软状态允许各个节点的数据同步存在延迟。

Eventually consistent

关于最终一致性,我们来看看维基百科的解释:

最终一致性(英语:Eventual consistency)是分布式计算里的一种内存一致性模型,它指对于已改变写的数据的读取,最终都能获取已更新的数据,但不完全保证能立即获取已更新的数据。这种模型通常可以实现较高的可用性。最终一致性,通过乐观复制,或称延迟复制(lazy replication)实现。这种概念最初始于移动应用,后来在各类分布式系统中也有广泛的应用。达到最终一致性的分布式系统被称为副本达到了"收敛(converged)"状态。

也就是说,系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取到最新的值。

BASE理论告诉我们,当我们的系统无法做到强一致性时,可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。所以说BASE理论面向的是大型高可用可扩展的分布式系统。

参考

1.CAP定理 - 维基百科,自由的百科全书 (wikipedia.org)-https://zh.wikipedia.org/wiki/CAP定理




往期推荐




【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论
【知识科普】分布式系统中你不得不了解的CAP定理与BASE理论

扫码二维码

获取更多精彩

Lvshen_9