CAP定理

CAP定理:一个分布式系统不可能同时满足一致性（Consistency）、可用性(Availability)、分区容错性(Partition tolerance)这三个基本需求，最多只能同时满足其中两个需求。

一致性：

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性 的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然 处于一致的状态。对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进 行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是 在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就 是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更 新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具 有强一致性（或严格的一致性）。

可用性：
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是 能够在有限的时间内返回结果。这里我们重点看下“有限的时间内”和“返回结果”。“有限的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间（即 响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，“有限的时间内”是一个在系统设计之初就设定好的系统运行指 标，通常不同的系统之间会有很大的不同。比如说，对干一个在线搜索引擎来说， 通常在0.5秒内需要给出用户搜索关键词对应的检索结果。以Google为例，搜索“分 布式”这一*关键词，Google能够在0.3秒左右的时间，返回大约上千万条检索结果。 而对干一个面向hive的海量数据查询平台来说，正常的一次数据检索时间可能在 20秒到30秒之间，而如果是一个时间跨度较大的数据内容查询，“有限的时间”有 时候甚至会长达几分钟。从上面的例子中，我们可以看出，用户对干一个系统的请求响应时间的期望值不尽相同。 但是，无论系统之间的差异有多大，唯一相同的一点就是对于用户请求，系统必须存在 一个合理的响应时间，否则用户便会对系统感到失望。“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理 后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结 果，即成功或失败，而不是一个让用户感到困惑的返回结果。让我们再来看看上面提到的在线搜索引擎的例子，如果用户输入指定的搜索关键词后， 返回的结果是一个系统错误，通常类似于“OutOfMemoryError”或System Has Crashed”等提示语，那么我们认为此时系统是不可用的。

分区容错性
分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区 故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络 环境都发生了故障。网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等) 中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的 内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要 注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。以上就是对CAP定理中一致性、可用性和分区容错性的讲解，通常使用图1-2所示的示 意图来表示CAP定理。既然在上文中我们提到，一个分布式系统无法同时满足上述三个需求，而只能满足其中 的两项，因此在进行对CAP定理的应用时，我们就需要抛弃其中的一项，表1-1所示是 抛弃CAP定理中任意一项特性的场景说明。

表1-1. CAP定理应用

放弃P	如果希望能够避免系统出现分区容错性问题，一种较为简单的做法是将所有 的数据（或者仅仅是那些与事务相关的数据）都放在一个分布式节点上。这样 的做法虽然无法100%地保证系统不会出错，但至少不会碰到由于网络分区带 来的负面影响。但同时需要注意的是，放弃P的同时也就意味着放弃了系统的 可扩展性
放弃A	相对于放弃“分区容错性”来说，放弃可用性则正好相反，其做法是一旦系 统遇到网络分区或其他故障时，那么受到影响的服务需要等待一定的时间，因 此在等待期间系统无法对外提供正常的服务，即不可用
放弃C	这里所说的放弃一致性，并不是完全不需要数据一致性，如果真是这样的话， 那么系统的数据都是没有意义的，整个系统也是没有价值的。事实上，放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。 这样的系统无法保证数据保持实时的一致性，但是能够承诺的是，数据最终会 达到一个一致的状态。这就引入了一个时间窗口的概念，具体多久能够达到数 据一致取决于系统的设计，主要包括数据副本在不同节点之间的复制时间长短