- 特指 linearizability Consistency
- CAP根本没有提到延迟(latency),满足CAP可用性的系统可以花任意长的时间来回复一个请求.
- CAP系统的模型是一个只能读写单个数据的寄存器,事务(transaction)不在这个定理的范围之内
- 在设计分布式系统的时候，你需要考虑到更多得多的问题。如果太关注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可用性的系统可以花任意长的时间来回复一个请求，而且同时保持可用性这个属性。
我来冒险说一句，我猜如果你的系统要花两分钟来加载一个页面，你的用户是不会称它是“可用的”。