深入理解 CAP 定理

• 什么是 CAP 定理
• 结点、系统、集群
• 一致性、可用性、分区容错性
• 一致性、可用性、分区容错性之间的区别
• 为什么不能同时满足 CAP
• 总结

什么是 CAP 定理

  CAP 定理是分布式系统中必定要了解的内容。它指的是，对于一个分布式系统，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）最多只能同时满足其中两个。

  什么是一致性、可用性、分区容错性呢？在介绍这几个概念前，先介绍本文需要涉及的三个概念：结点、系统、集群。

结点、系统、集群

• 结点：参与储存某数据的不可再分的服务器称为结点。

• 整个系统：参与储存某数据的所有结点构成整个系统。

• 集群：将整个系统对应的无向图分为若干互不相连的连通图。其中每个连通图对应一个集群。其中，无向图、连通图为离散数学中的概念，这里不做详解。

• 系统：参与储存某数据的若干集群构成一个系统。

【说明】

  此处是在数学层面上给出集群的抽象定义。在计算机领域中，集群指的是满足如下条件的进程的集合。

• 这些进程之间相对独立（这些进程彼此之间没有进程创建上的父子关系）。

• 这些进程可以在同一个主机上，通过占用这台主机上不同的端口号来运行，也可以运行在不同的主机中，而这些主机之间可以通过计算机网络等通信技术来相互连接。

• 这些进程可以通过计算机网络等通信技术来同步它们之间的数据，从而使它们彼此之间的行为受到一定的制约。

• 这些进程之间都同时使用了计算机网络等通信技术之外的某一类技术，如 Redis 集群之间都使用了 Redis 技术，Zookeeper 集群之间都使用了 Zookeeper 技术等等。

  结点、集群、系统如图 1 所示。

  为了简化说明，本文再介绍如下约定及概念：

• 本文中的系统均指分布式系统。整个系统中可以只有一个集群，但不能只有一个结点。

• 客户端对服务端访问的最小粒度为系统。即客户端只能对系统进行通信，而不能直接与结点进行通信。

• 本文中的系统均为需要对外提供通信服务的系统，即便系统是内部发生故障之后也是如此。

• 当客户端对系统发出请求时，只要该系统中有一个结点进行了响应，就视为系统进行了响应。

• 集群中的所有结点必定是连通的。如果集群中某结点或链路发生故障，则该集群有可能变成多个集群。

• 数据：当客户端对系统发出请求时，系统反馈信息的全部内容。

• 数据版本：数据是可能时刻被更新的。某数据在某时刻的完整内容为该数据的一个数据版本。

• 系统中的最新数据：在系统所有的结点中，最新版本的数据。

• 本 CAP 定理是建立在极大似然估计、长期这个两个意义之上的。

  • 不管使用任何技术来防范，如果系统中所有的结点都长期同时发生故障，这都必定同时不满足 CAP 定理（一致性、可用性、分区容错性）中的任何一个。但这里认为 ：

    • 系统中所有的结点同时发生永久性故障 是不可能事件。

    • 系统中某结点发生永久性故障 是不可能事件。

    • 系统中某结点之间的链路短期发生故障 是可能事件。

    • 系统中某结点短期发生故障 是可能事件。当某结点短期发生故障时，也认为与该结点相连的链路也同时发生故障。

    • 短期所有结点、链路都不发生任何故障 是可能事件。

    • 故障是随机的，不可能使用某种算法提前准确预知的。

    • 数据总是时刻随机变化的，通过以往数据精确预知某数据的变化是不可能的。

  • CAP 是建立在长远来看的实现。短期是可能同时满足 CAP 的，CAP 定理针对的长期情况下的满足，而长期来讲，任何结点、链路都有可能发生故障。

  （极大似然估计、不可能事件、可能事件均为概率论中的概念，这里不做详解。）

一致性、可用性、分区容错性

  下面来解释什么是一致性、可用性、分区容错性。

• 一致性：当每次客户端对系统发出请求后，若直至该系统进行响应前，系统的连通性不发生变化。当该系统进行响应时，反馈的数据是 系统中的最新完整数据，则称该系统满足一致性。

  ---

  【注意】

  • 一致性是针对系统响应信息之时来说的。如果该系统不及时进行响应，不能认为该系统不满足一致性。即对于一致性，系统可以选择等到能保证一致性时再进行响应来保证。

    如果系统一直不进行响应，则这种情况对一致性来说是未定义的。即无法界定该系统是否满足一致性，但一般认为此时系统至少不满足可用性。研究人员可以增加附加条件来对此情况进行界定，比如强制规定一个最晚响应时间。如果系统超过这个时间没有进行响应，就认为该系统响应的是一个空白数据。此时就相当于将一直不进行响应当作是不满足一致性。

  • 如果系统中有某结点发生故障，则此时对客户端反馈的信息必定不能满足一致性。但认为没有结点会发生永久性的故障。

  • 本文中的系统均指分布式系统。系统中可以只有一个集群，但不能只有一个结点。不能通过在系统中只使用一个结点来达成一致性。

  • 任何结点上的数据都可能动态变化，不能认定数据未来不再变化而实现一致性。

  ---

• 可用性：若当每次客户端对系统发出请求，到该系统进行响应之间的时间，小于一个事先约定的定值，则称该系统满足可用性。

  ---

  【注意】

  • 此定值可长可短，但要是一个与“技术攻关用时”、“网络恢复通畅用时”无关的值。

  ---

• 分区容错性：对于不同的场景要求，可以是以下定义之一：

  • 对于有可能发生故障的链路，即便是已经发生故障，此时当每次客户端对任意系统发出请求后，该系统进行响应时，反馈的数据都令人满意，则称该系统满足分区容错性。

  • 对于有可能发生故障的链路，即便是已经发生故障，此时当每次客户端对任意系统发出请求后，该系统进行响应时，反馈的数据是任意一个版本的完整数据，则称该系统满足分区容错性。

    ---

    【注意】

    • 分区容错性中的分区，对应这里的系统。

    • 分区容错性是针对系统响应信息之时来说的。如果该系统不及时进行响应，不能认为该系统不满足分区容错性。即对于分区容错性，系统可以选择等到能保证分区容错性时再进行响应来保证。

    • 完整数据可以分散到系统的多个结点中。如果系统中所有结点合起来都不能提供完整的数据，则认为此时该系统不满足分区容错性。

      特别地，如果某系统中只有一个结点，则认为该系统不满足分区容错性。因为如果该结点故障，则该系统就不能对外提供服务。

    ---

一致性、可用性、分区容错性之间的区别

• 一致性、可用性之间的区别：

  这两个概念很容易区分，从略。

• 分区容错性、可用性之间的区别：

  这两个概念很容易区分，从略。

• 一致性、分区容错性之间的区别：

  一致性描述的是当系统没有发生故障时的响应情况。而分区容错性描述的是系统没有发生故障和已经发生可能故障时的响应情况，且一致性对响应的要求强于分区容错性。

  一致性与分区容错性描述的时系统在不同条件下的表现，它们之间没有包含关系，只是概念上有些相交。当一致性被满足时，分区容错性未必会被满足。

为什么不能同时满足 CAP

  假设已经满足了 CAP 中的两者：

• CP：如果满足了一致性，则系统中各结点必定连通。但系统的连通不是永恒的，如果由于关键性的故障，系统被分成多个集群，此时就需要一些时间来等待故障被消除，因此此时不能满足 A。

• AP：如果满足了可用性与分区容错性，说明系统中的各个集群都能做到独立工作和及时反馈。如果此时要求还要满足一致性，则会破坏它们之间的独立性，从而影响它们之中的可用性。

• CA：如果满足了一致性，则系统中各结点必定连通。如果同时满足 CA，则要求系统中各结点一直保持连通。这就会导致系统对链路故障零容忍。因为如果系统中发生了关键性的故障，系统内部将被划分成互不相连的多个集群。由于不能与其它集群进行通信，所以每个集群都不能保证自己的数据是最新数据，如果还要求它们即时反馈，则将不满足一致性。

总结

• CAP 之间的侧重点各有不同：

  • 一致性代表着系统之间能否实现数据同步。

  • 可用性代表着系统能否实现对外的即时反馈。

  • 分区容错性指的是系统之间的独立性。

• 一般会优先实现分区容错性、可用性。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！