CAP #

P 是前提 #

在理论计算机科学中，CAP 定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个 distributed data store 来说，不可能同时满足以下三点：

• 一致性（Consistency）
  • 每次读取要么获得最近写入的数据，要么获得一个错误。
• 可用性（Availability）
  • 每次请求都能获得一个非错误响应，但不保证返回的是最新写入的数据。
• 分区容错性（Partition tolerance）
  • 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。
  • 尽管任意数量的消息被节点间的网络丢失（或延迟），系统仍继续运行。
  • 分区指网络分区，通信的两台服务器之间网络断开，就发生了网络分区

一般选 AP #

也就是说，在存在网络分区的情况下，一致性和可用性必须二选一。

比如：A 服务器 B 服务器同步数据，现在 A B 之间网络断掉了，那么现在发来 A 一个写入请求，但是 B 却没有相关的请求，显然，

• 如果 A 不写，保持一致性，那么我们就失去了 A 的服务，
• 但是如果 A 写了，跟 B 的数据就不一致了，我们自然就丧失了一致性。

这里的一致性（Consistency）是强一致性，意思是 AB 的数据时刻都是同步的， 如果我们放弃了强一致性，不代表我们的数据就是一定是不一致的了，我们可以让 A 先写入本地，等到通信恢复了再同步给 B，这就是所谓的最终一致性，长远的看我们的数据还是一致的，我们只是在某一个时间窗口里数据不一致罢了。 如果这个时间窗口小过了用户逻辑处理的时间。那么其实对于用户来说根本感觉不到。

现实中的 CAP #

CAP 对实际工作缺乏指导性。

实际系统主要有三种：

• 强调 availability 的 eventual consistency 系统，
  • 比如 Amazon Dynamo 及他们的复制品；
• 强调一致性的系统，
  • 典型的是基于 Paxos 的系统；
• 强调性能不顾其他的系统，
  • 典型的是 Async replication 的主从备份系统。

参考 #

• CAP 理论常被解释为一种 “三选二” 定律，这是否是一种误解？
• 分布式事务中的最终一致具体应该如何实现？
• 分布式系统中的数据一致性和性能怎么权衡？