以CockroachDB为例，深入了解CAP定理

分布式计算

CAP 定理是分布式系统理论的基础，它的核心内容是说，在存在分区（如网络故障）的情况下，一个系统无法同时保证一致性（consistency）和可用性（availability），只能二选其一。

有些数据库选择了一致性，那么这类系统就被称为 CP 系统。而有些系统更看重可用性，也就是 AP 系统。一致性和可用性对于任何一个业务系统来说都是至关重要的，如何在这两者之间做出选择也就变成一个大难题。

这篇文章将说明如何在保证系统一致性的同时仍然能够保证高可用性，并以 CockroachDB 为例来解释 CAP 定理，以及为什么对于大多数数据库来说一致性更重要。

高可用性

在 CAP 定理里，可用性具有严格的二元性：一个系统要么可用，要么不可用。但在服务级别协议（SLA）里，可用性具有连续性。

例如，一个系统可以保证99.99%的可用性（4个9，也就是说每年允许宕机的时间不超过一个小时）。100%的可用性是不现实的。工程上的高可用性要求对各种中断的严重程度进行评估，并在降低故障率所要花费的成本上做出平衡。

一个具有一致性保证的系统有时候因为网络分区出现不可用，但即使是具有可用性保证的系统，也会因为各种原因出现不可用。在一个良好的网络环境里，因网络分区造成的故障不会比其他类型的故障更常见。既然故障是不可避免的，进而导致不可用，那为什么不先保证一致性呢？

Brewer 博士说 Google 的网络很少会出现分区，Spanner 数据库理论上是“CP”，但实际上几乎是“CA”的。这听起来有点跑题了，不过却也说明了在可用性方面做出一些权衡，其影响面不会太大。

合理的权衡

在分布式系统里，权衡无处不在，我们总是要在一致性、可用性、性能和灵活性之间做出权衡。而 CAP 定理将选择的范围缩小到一致性和可用性之间，但无法涵盖所有可能造成不可用的问题根源。

有各种原因可能造成系统中断，比如硬件单点故障、应用程序的缺陷或运维人员的人为错误。而从整个系统层面来看，如果能够处理好网络分区问题，那么就有可能在不牺牲一致性的前提下提升可用性。CAP 的可用性不一定会带来实质性的可用性保证，但如果牺牲了一致性，将会给应用程序的代码带来复杂性，也意味着更高的工程成本。

假设有一个应用程序，它部署在3个数据中心里，客户端的流量经过负载均衡器连接到应用程序上。如果其中的一个数据中心因网络故障掉线，那么连接到这个数据中心的客户端将会遭遇中断，而不管底层的数据库是 CP 还是 CA 的。而如果负载均衡器将这些中断的客户端流量重定向到活跃的数据中心，不管底层的数据库如何处理网络分区问题，服务仍然可用。

只有当数据中心复本之间无法通信而客户端仍然能够与各个数据中心对话时，AP 系统仍然可用，而 CP 系统不可用。如果把整个系统作为整体部署来考虑，可以不用遵循 CAP 定理所要求的需要每个节点都要返回响应的原则，从而达到高可用性。

如果 AP 系统所能带来的可用性价值不高，那么为什么要为此牺牲一致性呢？理由只有一个，因为写入延迟。一致性系统在执行写入操作的时候需要协调各个节点来保证一致性（当然，有些系统对一致性读也有很高要求）。非一致性系统允许丢失数据，所以可以很快返回响应。对于速度比健壮性更重要的系统来说，或许这会是更好的选择。

CockroachDB 的 CAP

CockroachDB是 CP 系统：每一份数据至少有3个复本，在写入数据时要求每个复本之间进行通信。在数据读取方面，其中的一个复本被授予一段时间的租期或一个数据子集的临时所有权，这个复本可以在不与其他复本通信的情况下处理读取请求。如果这个复本与其他复本失去联系，在租期内（默认是9秒钟）它仍然能够提供读取数据服务（但不能写入）。在租约到期之后，另外两个复本中的一个会得到新的租约。这样可以确保系统能够快速地从中断中恢复，提供最高的可用性，尽管它不符合 CAP 定理对可用性的定义。

CockroachDB的强一致性基因让它有可能为分布式数据库提供与传统的非分布式数据库一样的一致性保证，同时保持高可用。对于大多数应用程序来说，CP 数据库会是更好的选择，尽管存在潜在的延迟，但它也为开发者提供了一些保证。

• 大部分最近的写入对后续的读取是可见的。
• 其他开发人员无法破坏应用整体的一致性。
• 发生分区事件时，系统会阻塞，而不是返回不完整的数据。