CAP

CAP定理又被称为布鲁尔定理(Brewer's),对一个分布式系统来说,最多只能同时满足以下三点中的两点:

  • 一致性(Consistency):所有节点访问同一份最新的数据副本
  • 可用性(Availability):分布式系统提供的数据或服务处于一直可用的状态
  • 分区容错性(Partition tolerance):指系统在遇到网络分区故障时,仍然可以对外提供服务。

    例如A和B两个系统,当中间网络不通时,那么当A接收到读请求时,就可能读到旧数据,也就意味着,要么等通信恢复,数据同步之后进行读,这样虽然保证了一致性,但是导致不满足可用性;要么舍弃一致性,让A B都能读写
    现实中,网络分区故障经常会出现,导致不得不在追求一致性还是高可用之间做出取舍,很多NoSQL数据库(如Cassandra)会选择追求高可用性,而像关系型数据库会为了遵循ACID原则(原子性、一致性、隔离性和持久性)而追求一致性。
    CP或者AP,通常CP用在对数据一致性很高的场景,比如交易;而AP用在诸如缓存,CDN网站更新等。

Base

BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网分布式系统实践的总结,是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性,但每个应用都可以根据自身业务特点,才用适当的方式来使系统打到最终一致性。

  • Basically Available:基本可用)
  • Soft State:软状态
  • Eventually Consistent:最终一致性
    下面展开讨论:

基本可用

假设系统出现了不可预知的故障,但还是能用,相比较正常的系统而言:

  1. 响应时间上的损失:正常情况下的搜索引擎0.5秒即返回给用户结果,而基本可用的搜索引擎可以在2秒作用返回结果。
  2. 功能上的损失:在一个电商网站上,正常情况下,用户可以顺利完成每一笔订单。但是到了大促期间,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。

软状态

相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种“硬状态”。
软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时

最终一致性

上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性,从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
而在实际工程实践中,最终一致性分为5种:

  1. 因果一致性(Causal consistency)
    因果一致性指的是:如果节点A在更新完某个数据后通知了节点B,那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时,和节点A无因果关系的节点C的数据访问则没有这样的限制。
  2. 读己之所写(Read your writes)
    读己之所写指的是:节点A更新一个数据后,它自身总是能访问到自身更新过的最新值,而不会看到旧值。其实也算一种因果一致性。
  3. 会话一致性(Session consistency)
    会话一致性将对系统数据的访问过程框定在了一个会话当中:系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性,也就是说,执行更新操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。
  4. 单调读一致性(Monotonic read consistency)
    单调读一致性指的是:如果一个节点从系统中读取出一个数据项的某个值后,那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
  5. 单调写一致性(Monotonic write consistency)
    单调写一致性指的是:一个系统要能够保证来自同一个节点的写操作被顺序的执行。
    在实际的实践中,这5种系统往往会结合使用,以构建一个具有最终一致性的分布式系统。
    实际上,不只是分布式系统使用最终一致性,关系型数据库在某个功能上,也是使用最终一致性的。比如备份,数据库的复制过程是需要时间的,这个复制过程中,业务读取到的值就是旧的。当然,最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。
    总体来说BASE理论面向的是大型高可用、可扩展的分布式系统。与传统ACID特性相反,不同于ACID的强一致性模型,BASE提出通过牺牲强一致性来获得可用性,并允许数据段时间内的不一致,但是最终达到一致状态。同时,在实际分布式场景中,不同业务对数据的一致性要求不一样。因此在设计中,ACID和BASE理论往往又会结合使用。