本节书摘来自异步社区出版社《解读NoSQL》一书中的第2章，第2.7节，作者： 【美】Dan McCreary（丹•麦克雷） , Ann Kelly（安•凯利），更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.7　基于Brewer的CAP定理进行权衡

为了能在系统故障时做出最好的决策，你需要考虑基于不可靠的网络的分布式系统的一致性和可用性属性。

Eric Brewer在2000年首次提出CAP定理。CAP定理表明了任何分布式数据库系统最多只能满足以下3个期望属性中的2个。

一致性——对于所有客户端，具有唯一的、最新的、可读的版本的数据。这和前面讨论的ACID的一致性不太一样。这里的一致性主要关注的是多个客户端从多个复制分区读取相同的内容并得到一致的结果。

高可用性——我们知道分布式数据库总是允许数据库客户端无延迟地更新内容。在副本数据之间，内部通信故障不应妨碍更新操作。分区容错性——即使数据库分区之间存在通信故障，系统仍然保持响应客户端请求的能力。这好比即使大脑部分之间的联系出现问题，人仍然可以进行有智力的对话。记住，CAP定理只适用于集群中出现连接故障的某些情况。网络越可靠，需要考虑CAP定理的可能性就越低。

CAP定理可以帮助你理解一旦将数据进行分区，就必须考虑在网络出现故障的情况下，可用性-一致性所能承受的范围。CAP定理让用户自己决定哪个选项最适合业务需求。图2-10展示了一个CAP定理适用的示例。

图2-10　分区决策。CAP定理可以帮助你在网络故障时，在可用性和一致性相对的优缺点之间做出取舍。在左图中，客户端执行一个正常的写操作，首先将写入主节点，然后再通过网络将数据复制到从节点。如果网络出现故障，客户端API决定了可用性或者一致性的相对度量。在中间的图中，你接受了写操作并承受了可能会从从节点读到不一致数据的风险。在右图中，你选择了保证一致性并阻塞了客户端写操作直到数据中心之间的连接恢复

客户端写入首要的主节点，主节点再向另一个备份的从节点复制数据。CAP迫使用户考虑中节点之间连接出现故障时是否接受一个写操作。如果你接受写操作，那么需要负责确保远程节点稍后会进行更新，并且将承受在连接恢复之前，客户端有可能读到不一致的数据的风险。如果拒绝客户端写入，那么牺牲了可用性，客户端必须稍后重试。

尽管CAP定理在2000年就提出了，但它仍然会引起困惑。CAP定理通过一些罕见的终结案例限制了设计选型，并且CAP定理只适用数据中心之间发生网络故障的情况。大多数情况下，可靠的消息队列能够很快地在故障后恢复数据一致性。

CAP定理适用的规则如图2-11所示。

图2-11　CAP定理说明如果只使用一个处理器，可以兼顾一致性和可用性。如果使用多个处理器，只能基于事务类型、用户、预计的故障时间或者其他因素在一致性和可用性之间做出选择

像CAP定理这样的工具可以帮助指导组织内部数据库选型的讨论并且确定哪些属性（一致性、可用性和扩展性）才是最重要的。如果严格的一致性和更新可用性同时需要，那么更快的单个处理器可能是最好的选择。如果需要分布式系统提供的扩展能力，那么要基于需求为每个事务类型在更新可用性和读一致性之间做出选择。

无论选择哪个选项，CAP定理提供了一个能帮助你权衡每个SQL或者NoSQL系统利弊的标准流程，而最终，你将会做出一个明智的决定。