centos7打包成docker镜像

1. CAP 的由来

要理解 CAP，首先我们要清楚，为何会有人提出 CAP？他提出 CAP 是为了解决什么问题？

时间回到 1985 年，彼时，后来证明了 CAP 理论的 Lynch 教授此时给当时的 IT 界来了一记惊雷：

她通过不可辩驳的证明告诉业界的工程师们，如果在一个不稳定（消息要么乱序要么丢了）的网络环境里（分布式异步模型），想始终保持数据一致是不可能的。

这是个什么概念呢？就是她打破了那些既想提供超高质量服务，又想提供超高性能服务的技术人员的幻想。

这本质是在告诉大家，在分布式系统里，需要妥协。

但是，如何妥协？分布式系统里到底应该怎么权衡这种 trade-off？

我们可以想象一下，在 CAP 定理提出之前，没有这些方向性的指引，在设计和实施分布式系统时该有多么混乱。一套分布式系统是由多个模块组成的，这些模块本身可能由不同的开发人员去完成。然而，对于这些人，在公共层面，竟然没有一个原则去指导他们该怎么完成这套功能。

比如，我们在同步两个节点的数据时，如果发生了错误，到底我们应该怎么做呢？如果没有统一的标准和方向，那很可能在一套分布式系统中的不同模块，会出现不同的处理情况。

假设一套系统，由 A、B 两个模块构成。

A 模块的设计理念是：节点间出现了问题，它可能会选择不断的重试，一直等到节点通信恢复。

而 B 的设计理念是：节点间出现了问题，它断开就是了，可能最多就记录下状态，等以后处理。

可是，当 A、B 之间出现了通信怎么办？那会出现 A 往 B 发请求，出问题会不断重试。而 B 往 A 发请求，出问题则直接断开的情况。

当然，在后面我们会说明，CAP 的理念在实际工程中，会允许这种不一致。可是，那种不一致是提前设计好和规划好的，是根据实际数据的重要性和业务需求做的妥协，而不是这种混乱的妥协。

所以，IT 界的人们就一直在摸索，试图找到一些纲领去指导分布式系统的设计，这一找就找了 15 年。

2000 年时，Eric Brewer 教授在 PODC 会议上提出了 CAP 理论，但是由于没有被证明过，所以，当时只能被称为 CAP 猜想。这个猜想引起了巨大的反响，因为 CAP 很符合人们对设计纲领的预期。

在 2002 年后，经过 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想后，CAP 理论正式成为了分布式系统理论的基石之一。

2. CAP 到底是什么

CAP 定理表达了一个分布式系统里不可能同时满足以下的三个特性：

2.1. C：数据一致性

什么是数据一致性？咋一看真的很让人糊涂，一致性是什么？是指数据能一起变化，是能让数据整齐划一。

那么问题又来了，数据何时会变化？数据怎么才能被称为一起变化？我们现在来回答这些问题，当我们搞清楚了这些问题，那么对数据一致性就会有了清晰的理解。

首先第一个问题，数据何时会一起变化？

答案是：仅且仅当包含数据的服务，收到数据更新请求的时候，数据才会发生变化。而数据更新请求则仅包括数据的增、删、改这三种请求，而这三种请求又被统称为写请求。所以，数据只有在写请求的时候才会发生变化。

那我们来回答第二个问题，数据要怎么样才能被称为一起变化了？即谁来判断数据是最终变化了？是服务器对写请求的返回结果吗？告诉写请求成功，数据就一定发生一致性变化了？

NO，数据发生变化是否一致是需要经过读请求来做检验的。那么读请求判断的依据是什么呢？

假设，我们的分布式存储系统有两个节点，每个节点都包含了一部分需要被变化的数据。如果经过一次写请求后，两个节点都发生了数据变化。然后，读请求把这些变化后的数据都读取到了，我们就把这次数据修改称为数据发生了一致性变化。

但是，这还不是完整的一致性。因为系统不可能永久的正常运行下去。

如果系统内部发生了问题从而导致系统的节点无法发生一致性变化会怎么样呢࿱