分布式思考：好不要用CAP去分析问题

## 前言

在很多分布式问题分析中，有人喜欢先介绍CAP或用CAP这个词开篇。作为一个广泛使用的大词（Buzzword），CAP并不是一个很适合分析分布式的工具或词汇，它存在很多自身的问题，下面为你做详细的剖析。

## CAP的本义

CAP，是下面三个单词Word（或短语Phrase）的首字母的组合，如下：

* Consistency，中文意思：一致性
* Availability，中文意思：可用性
* Partition Tolerance，中文意思：分割忍耐性

具体的含义是：

在分布式系统里，你的设计，只能保证从上面三个单词里选取两个，但不可能三个全得。即：

你的分布式系统，要么：

1. CA，但不允许有P。即你的分布式系统，可以即保证一致性Consistency，同时保证可用性Availability，但不能出现系统分割Partition

2. CP，如果你的分布式系统出现了系统分割Partition，你可以保证你的数据的一致性Consistency，但是，此时，你的系统，必须牺牲可用性Availability

3. AP，如果你的分布式系统出现了系统分割Partition，你可以保证你的系统继续可用Availability，但是，此时，你的系统，不能保证数据一致性Consistency

CAP是一种trade off思想，即你不能好处全得，你获得什么，也就意味你失去什么。比如：

* CA，失去P；
* CP，失去A；
* AP，失去C。

下面我们看看，如何攻击上面的这个CAP定义。

## 故意关闭或crash集群部分机器

假设我有一个集群系统，有N台机器，我故意Crash几乎所有的机器，只留下后一台。

我让后一台机器继续保持对外服务，同时数据一致（因为数据只有一份，所以一致性Consistency非常容易保证）。

然后，我宣称：CAP破产。因为，我制造了Partition，其中一个Partition只剩一台机器，并对外继续提供Consistency和Availability，然后另外一个Partition是所有崩溃的机器，而且，我忍耐了它。

于是，为了让CAP不破产，CAP需要修正案

Partition，不能是简单地crash系统。

它必须是基于网络，由网咯产生分割，

而且每个Partition必须至少有1台机器活着。即我们不考虑crash掉的死机器