经典的CAP理论

CAP理论在互联网界有着广泛的知名度，被称为“帽子理论”，它是由Eric Brewer教授在2000年举行的ACM研讨会上提出的一个著名猜想:一致性(Consistency)、可用性(Availability),分区容错(Partition-tolerance）无法在分布式系统中被同时满足，并且最多只能满足其中两个!2003年，MIT的Gilbert和 Lynch 正式证明了这三者确实是不可兼得的。而后CAP被奉为分布式领域的重要理论，被很多人当作分布式系统设计的金律。

Brewer教授当时想象的分布式场景是在一组 Web Service后台运行着众多Server,对 Service的读写反映给后台的Server集群，并对CAP给出了如下定义。

一致性（C):所有节点上的数据都时刻保持同步。可用性（A):每个请求都能接收一个响应，无论响应成功或失败。分区容错(P):系统应该能持续提供服务，即使系统内部(某个节点分区)有消息丢失。

一致性与可用性属于分布式系统的固有属性。分区容错是网络相关的一个属性，常见的几种分区如下。

交换机失败，导致网络被分成几个子网，形成脑裂。服务器发生网络延时或死机，导致某些Server 与集群中的其他机器失去联系。

现在我们明白了，分区是分布式系统固有的可靠性问题所导致的一个紊乱的集群状态。从这三个概念的本质来看，CAP理论的准确描述不应该是从3个特性中选择两个(2/3)，因为分区本身就是分布式集群固有的特性，我们只能被迫适应，根本没有选择权!有人就此质疑并且提出CAP理论应该如下所示描述。

在一个允许网络发生故障(P）的系统中，我们设计分布式系统时应该选择哪一个目标:保持数据一致性(C）还是系统可用性(A）?

当集群中的机器数量持续增加时,一致性会加剧系统的响应延时,同时导致资源消耗加剧，使维护一致性的成本非常高，在这种情况下，我们基本上只剩下一种选择:在允许网络失败的系统中，更多地选择可用性而放弃一致性。而ZooKeeper、Hadoop之所以选择一致性，是因为这些系统多数是由少量节点所构成的分布式集群!

在CAP理论出来以后，各种质疑不断，有人提出:应该放弃分区容错，因为在局域网中分区很少发生;而在广域网中有各种备选方案，导致实际的分区也较少发生，并且很多人一致认为分区同时蕴涵着不可用，这两个概念之间存在重叠。还有一些重要的质疑包括CAP无法用于分布式数据库事务，比如应用因为更新一些错误的数据而导致失败，此时无论使用什么样的高可用方案都是徒劳的，因为数据发生了无法修正的错误!也有质疑者结合了数据分区导致不可用的一些案例，说明CAР理论并不能用于分布式数据库事务领域。

面对铺天盖地的质疑,在CAP理论诞生12年后,CAP之父Brewer和 Lynch纷纷出来澄清。首先是 Brewer 给出重要修订:“3个中的两个”这个表述是不准确的，这个说法过于简化了复杂场景和问题领域;在某些分区极少发生的情况下，三者能顺畅地配合。

Lynch也在2012年重写了之前的论文，该论文的重点如下。

把CAР理论的证明局限在原子读写的场景中，并声明不支持数据库事务之类的场景。把分区容错归结为一个对网络环境的陈述，而非之前的一个独立条件。这实际上更加明确了概念。引入了活性(Liveness)和安全属性(Safety)，在一个更抽象的概念下研究分布式系统，并认为CAP是在活性与安全属性之间权衡的一个特例。其中一致性属于活性，可用性属于安全性。

把CAP的研究推到一个更广阔的空间:网络存在同步、部分同步;一致性的结果也从仅存在一个到存在N个（部分一致);引入了通信周期Round，并引用了其他论文，给出了为了保证N个一致性结果，至少需要通信的Round 数量。还介绍了其他人的一些成果，这些成果分别对CAP的某一方面做出了特殊贡献。

我们不难发现，Lynch在论文中主要做了如下事情。

承认分区容错是一个既定的环境约束，而非独立的选择或者条件。缩小CAP适用的定义，消除质疑的场景。建立更精确的理论模型。暗示CAP理论依旧正确。

这里总结一下CAP理论:可以肯定的是，CAP并非一个放之四海而皆准的普适性原理和指导思想，它仅适用于原子读写的 NoSQL场景中，并不适用于数据库系统;当今的分布式系统早已不是十年前的简单系统了，现在分布式系统有很多特性如扩展性、自动化等，架构师在进行系统设计和开发时，视野要更加开拓，而不仅仅局限在CAP问题上。

BASE准则，一个影响深远的指导思想

从前面的分析中我们知道:在分布式（数据库分片或分库存在多个实例上）系统下，CAP理论并不适用于数据库事务。此外，XA事务虽然保证了数据库在分布式系统下的ACID特性，但也带来了一些代价，特别是性能方面的问题，这对于并发和响应时间要求比较高的电子商务平台来说是难以接受的。于是，eBay 公司尝试了完全不同的路，选择了放宽数据库事务的ACID要求，提出了一套名为BASE(BasicallyAvailable,Soft-state,Eventually Consistent，主要可用、软状态、最终一致性)的新准则，于2008年在ACM 上发布了一篇BASE的说明文章In partitioneddatabases,trading some consistency for availability can lead to dramatic improvements in scalability,并且给出了他们在实践中总结的基于BASE 准则的一套新的分布式事物的解决方案。

相对于CAP来说，BASE 准则大大降低了我们对系统的要求。其中 Basically Available 的一个解释案例如下:

我们的数据库采用了分片模式(partitioned)，比如将100万个用户数据分在5个数据库实例上，如果破坏了其中一个实例，那么可用性还有80%，即 80%的用户都可以登录，所以系统仍然是主要可用的。

那么，如何理解Soft-state这个概念呢?在 Distributed Systems Principles and Paradigms, 2nd一书里提到，在基于Client-Server 模式的系统中，Server是有状态的(stateful)还是无状态的( stateless)，这是一个很重要的设计思路，也在根本上决定了一个分布式系统是否具备良好的水平扩展、负载均衡、故障恢复等高级特性。然而，除了stateless 和 stateful，还存在另外一种方式——soft state，它最早来源于计算机网络中的协议设计( protocol design)，在分布式系统中的含义如下:

Server端承诺会维护Client的状态数据，但是“仅仅维持一小段时间”，过了这个时间段，Server 就会将这些状态信息丢弃，恢复正常的行为状态。

Eventually Consistent 指的是数据的最终一致性，而不是强一致性，之前提到过这个概念。从上面的分析解释来看，BASE 准则的思想其实就是牺牲数据的一致性来满足系统的高可用性，在系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

针对数据库领域，BASE思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，目前主要有以下两种做法。

按功能划分数据库。分片（如开源的 Mycat、Amoeba等)。

由于拆分后会涉及分布式事务问题，所以 eBay在该BASE 论文中提到了如何用最终一致性的思路来实现高性能的分布式事务。

本文给大家讲解的内容是架构解密从分布式到微服务：经典的CAP理论与BASE 准则下篇文章给大家讲解的是架构解密从分布式到微服务：带大家重新认识分布式事务；觉得文章不错的朋友可以转发此文关注小编；感谢大家的支持！