重新认识CAP 定理.


  1. 特指 linearizability Consistency
  2. CAP根本没有提到延迟(latency),满足CAP可用性的系统可以花任意长的时间来回复一个请求.
  3. CAP系统的模型是一个只能读写单个数据的寄存器,事务(transaction)不在这个定理的范围之内
  4. 在设计分布式系统的时候,你需要考虑到更多得多的问题。如果太关注CAP就容易导致忽略了其他重要的问题

记录 请不要再称数据库是CP或者AP (Please stop calling databases CP or AP) 的关键点

CAP的证明用的是非常具体的定义。

  • 一致性(Consistency)
    在CAP中是可线性化的意思(linearizability)。而这个是非常特殊(而且非常强)的一致性。
    尤其是虽然ACID中的C也是一致性(Consistency),但是和这里的一致性没有任何关系。我会在后面解释可线性化是什么意思。
  • 可用性(Availability)
    在CAP中是定义为”每一个请求(request)如果被一个工作中的[数据库]节点收到,那一定要返回[非错误]的结果”。
    注意到,这里一部分节点可以处理这个请求是不充分的。任意一个工作中的节点都要可以处理这个请求。所以很多自称”高度可用”的系统通常并没有满足这里的可用性的定义。

  • 分区容错(Partition Tolerance)
    基本上就是说通信是在异步的网络中。信息是可能延迟送达或者被丢失的。互联网还有我们所有的数据中心都有这个属性。所以我们在这件事上并没有选择。

还有就是注意到CAP并没有描述任意一个老的系统,而是一个非常特殊的系统:

CAP系统的模型是一个只能读写单个数据的寄存器。这就是全部。

CAP没有提到任何关于关系到多个事物(object)的事务(transaction)。他们根本就不在这个定理的范围之内,除非你可以把这些问题约化到一个单个寄存器的问题。

CAP定理只考虑了网络分区这一种故障情况

(比如节点们还在运行,但是他们之间的网络已经不工作了)。 这种故障绝对会发生,但是这不是唯一会出故障的地方。

分布式系统一定会出现下面这些问题.

  • 节点可以整个崩溃(crash)或者重启
  • 你可能没有足够的磁盘空间
  • 你可能会遇到一个软件故障(bug)
  • 等等。

在建分布式系统的时候,你需要考虑到更多得多的问题。如果太关注CAP就容易导致忽略了其他重要的问题。
还有CAP根本没有提到延迟(latency)。而常常人们其实对关心延迟比可用性更多。
事实上,满足CAP可用性的系统可以花任意长的时间来回复一个请求,而且同时保持可用性这个属性。
我来冒险说一句,我猜如果你的系统要花两分钟来加载一个页面,你的用户是不会称它是“可用的”。

,

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: