cap 理论中，感觉没法牺牲分区容忍性，而保证可用性和一致性啊。牺牲分区容忍性的话，那么一旦分区，可用性就无法保证。是我理解的有偏差吗，求 v 友纠正

[jdz]

[liprais]

为啥

[jdz]

@liprais 我理解无法容忍分区，那么分区后还能可用吗？

[hobochen]

"cap 理论中，感觉没法牺牲分区容忍性，而保证可用性和一致性啊"

对；这就是 CA 系统

[hobochen]

hmmm 原谅我读了两遍你的问题

不对

简单的例子：有一个 service 是强一致 cache，只读不写；显然它们是一致的，并且分区不会影响可用性（只要读请求 hit 到任何一台机器都可以）

[ethego]

是的，对于分布式系统来说一般必须容忍出现分区，剩下的只能在 C 和 A 中权衡。

[neoblackcap]

@hobochen 不行的，分区容忍性是必然存在的。你所说的只读不写。你想想存在这样的应用吗？整个集群就返回一个常量表？
现实生活中必然有写的操作，一旦不将分区容忍性考虑进去。强一致性就无从谈起了。CAP 实际上只有 CA 可以选，P 是必然存在的，不存在 CA 系统

[lhx2008]

如果出现分区问题，保可用性的方法一般就是 cache，像 dns 这种，一个分区的数据可能都是旧的。
如果要保一致性，那么就是小的那个分区不可用，大的分区还能用，像 zookeeper

[lhx2008]

像 zookeeper 的话，5 个节点，现在变成 3 2 两个分区，小的分区两个都是不能用，3 个的那个分区还能用

[lcdtyph]

对，P 是默认的，可选的只有 C 和 A

[az467]

你想的没错，一个 CA 的分布式系统，如果没有分区容错性，那么一旦出现分区，这个系统就会崩溃，一个崩溃的系统当然什么都无法提供。
不过，还是有办法保证 CA 的，只要想办法让分区不发生就好。

至于分区能不能避免，这个就不是 CAP 理论的内容了。
现实生活中我们一般都是认为不能。

个人觉得 CAP 理论的描述挺烂的，给人一种硬往「不可能三角」上凑的感觉。

[littlefatpaper]

本人刚学的时候也是各种翻资料，下面说下我的理解，希望对你有帮助：
先把每个拆分得概念理解清楚，然后依赖一些生活场景加以联想

C 一致性：保证同一时间访问所有节点的数据都是一致的
A 可用性：在系统中一部分节点故障后，系统是否还能响应客户端的读写请求。
P 分区容错：系统不能在时限内达成数据一致性，就是发生了分区（以上是 Wiki 的解释）。由于计算机中没有百分百可靠的通信协议（通信原理、计算机网络的内容），所以系统内肯定会存在部分节点在时限内无法通信，而造成数据不一致的问题。所以 P 是肯定是满足的。

一致性其实细分还可分为：强一致性（一个节点更新，其他节点也要更新），最终一致性（只要保证后续某一时刻访问，系统）
假设分布式系统中，由于 P 的客观存在，一个节点挂了（短时间内无法和系统内其他节点同步数据），而其他节点数据有更新。要满足一致性，必须等其他数据必须要同步数据到该节点，才允许客户端访问。要是满足可用性，系统在向客户端提供服务的时候，已经无法保证系统内的数据一致了。
综上，分布式系统 CAP 最多只能满足两个条件，其中 P 是必须有的，无法同时满足 CAP。

剩下有种情况 CA 也是讨论很多的，既然排除了 P，那系统需在时限内保证数据一致，那单体架构单节点是最稳的了。那还要保证一致性，单节点就一份数据，完全一致。而可用性，要么继续服务，要么整个挂。

[mcfog]

“牺牲分区容忍性”的意思是不支持分区，而不是分区后会怎样

cap 是三个互相独立的维度，可用性和是否分区无关，一个系统不分区也不一定默认就是可用的，例如磁带机只能顺序读取且寻道时间很长，那么在业务是十个消费者一起随机读写数据，单台磁带机就是不具备分区容忍性的同时没有可用性

[inwar]

理论的完整在于它包含所有可能情况的假设

[q447643445]

这个要看从什么角度来看吧. 分两个情况, 数据是否可用 和 服务是否可用
1.如果从数据可用的角度来看.丢掉分区容错 p 即可满足 数据一致性 c 可用性 a
2.如果从服务可用的角度来看.丢掉分区容错 p 可用性 a 也没有了 只能满足 数据一致性 c.

如果描述的是数据是否可用 也分两种情况:
1.如果描述的分布式系统 分区容错 p 就注定存在 只能 数据一致性 c 和数据可用性 a 二选一
2.如果描述的是系统架构 分区容错 p 就可以丢掉 成为数据可用数据一致的单点系统, 数据无法保证可用的 cp 分布式系统 ,数据无法保证一致的 ap 分布式系统,


在讨论这个 cap 的时候 我觉得很容易谈混淆

[hobochen]

@neoblackcap 所以 zookeeper 这样的系统只有 C ？居然不是 AC ？

[clrss]

只要保证不分区就可以了，但显然一般都不能保证

[hobochen]

@neoblackcap 看起来是我对 AC 的理解有些问题...

[lewis89]

@hobochen #15 他表述有问题，实际上就 CP AP 两个可以选，没有 CA CA 是单体不能严格算作分布式系统

AP 高可用就是 redis 集群模式，每次写副本都是异步同步，通常在副本实例里面读到历史版本也是可以容忍的，但是最终会读到最新的版本

CP 不高可用就是 zookeeper 每次写完，要所有的副本同步完此次写才算是成功写完，此时其它的请求想读这条数据没门，因为数据压根没同步完，在请求方看来 这就是一个强一致性的系统，虽然系统内部可能节点状态不一定统一，但是对外，会看到一个一致性的集群。

要理解 CAP 首先要理解强一致性，CP AP 其实本质上就是 系统内部节点的数据同步的两种形式，AP 系统可以容忍读取到历史版本数据（在互联网行业通常如此，C 端用户并没有太高的数据一致性需求），CP 不能容忍读取到历史版本数据 就这么简单，不要搞复杂了。

[neoblackcap]

@hobochen CA 的选择不是整个系统要选，你大可这一次操作选择 CP，另外的一个操作选择 AP。所以选择一致性还是可用性是这样选。不是一定说你这个系统就是强一致性就不能有高可用性。这个权衡不是一次性的，可以多次的。
至于 zk 是不是 AC， @lewis89 已经说明了。
高可用跟一致性不是两个极端，我大可放松一些求最终一致性，然后同时获得更高的高可用性。但是这就不是什么 CA 系统。因为你在满足强一致性的情况下，做不到高可用。要不你就搞单机系统

[mtrec]

cap 的粒度可以很小 不是说一个 cp 系统就所有操作都是 cp 大部分时间系统都可以保持 cap 只是某些异常时刻要做出抉择牺牲一个