CAP

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 的主从备份系统。

参考 #


本文访问量

本站总访问量

本站总访客数