分布式 基本理论 CAP 之 各分布式系统的cap支持情况

分布式系统、理论、协议 非常非常多， 它们多cap 的支持是怎么样的呢？

需要注意的是，分布式系统 为了应付各种 复杂 应用场景，支持各种各样的功能，可能有的提供了选项或某种机制， 某个时刻，支持CP，另外某个时刻 又变成了支持AP 等等等

角色不是一成不变的。CAP 的出现是2000 年， 现在差不多18年过去了，当时的 论点，在现在看来， 可能就是不充分， 有问题的！ CAP 的“三选二” 争议非常大，很多专家认为它是一个伪命题。

CAP 的关键论据其实是说，发生网络问题的时候，节点之间的“数据复制” 是无法迅速完成的。 其实这不就是废话吗？这是不证自明的！

我们看看各分布式系统的大致的 cap支持情况。

CA without P：

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，CA系统基本上是单机系统，比如单机数据库。2PC是实现强一致性的具体手段。

CA without P 其实表明了 不能出现 任何网络问题 （包括了 节点失败）， 一旦出现 那么 系统就整个不可用了。 对于单点系统来说， 其实是没有网络问题的，P 可以理解为 单点失败。 单点故障问题， 其实 就是  P 的问题。 反过来说，能够保证P， 那么 就不会有 所谓的 单点问题了！！

说明一下：

单机数据库 容易保证AC， 但 出现网络问题，那么系统 将不可用，这个容易理解。 但 集群数据库呢？

LDAP 好像是也是单机系统。LDAP 不允许任何的网络问题， 否则LDAP 系统整体都不可用。

xFS 不太理解。

2pc 任何一个节点失败或者出现网络问题， 那么肯定的 整体都不可用了。 （3pc 呢？  允许phase3 的时候 协调者挂掉？） 怎么说呢， 要求强一致性C，同时又要求整体可用， 那么就必然失去了A。而 对于2pc 和3pc 来说，其实可以说A 是P 的基础之上的，只要失去部分A， 那么P 也就没有了意义！ 因为 我们需要所有的节点 都返回Yes 才会继续commit， 否则 一概 rollback。 所以 AP 必然是同时的失去。 这种情况下，C 确实是可以保留的，但是它也就没有了意义。

缓存验证协议？ 不好理解

CP without A：

如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

说明一下：

分布式数据库，选择了C即一致性，出现网络问题的时候，会导致系统不可用即 牺牲了 A， 这个具体怎么回事呢？ 这里的分布式数据库 特指 Redis， MongoDB，HBase，当主节点出现网络问题的时候，整体失去了写的功能，即失去了A，但是从节点仍然是可以 读的，故C 保留了。不知道这么理解对不对。 另外， 我认为 这个仅仅是针对主节点down 掉的情况，如果 剩余的从节点 重新选举呢？ 如果出问题的是 某个从节点呢？如果Redis系统中有多个主节点呢？ 所以， 上面的图， 实在太笼统了，很多情况根本没说明， 不可当真！应该按照实际部署 和 软件本身提供的功能来看，绝不能一概而论，简单的说，Redis 就是CP。

• CA：传统Oracle、mysql数据库
• AP：Tokyo Cabinet、SimpleDB、couchDB、Riak

• CP：redis、mongodb

分布式锁： 为什么它也是CP？ 不好理解

多数决定协议：？不好理解

AP wihtout C：

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。—— 这句话我觉得有问题，前面我们已经看到了 Redis， MongoDB 属于 CP 的成分更多一些。 当然，这种分类其实意义不大。

特别的说一下DNS，DNS 肯定是AP！为什么是AP的？其实还是比较好理解的， 当一个DNS 网络出现网络问题的时候，出现问题的小分区，和 大分区都是 仍然保持读写的，即保持可用。 那么C 就必然的失去了！ 因为我们一般来说 要求DNS 容错，然后又要求继续提供服务（ DNS 可以通过其内部的缓存继续进行 服务，DNS 解析不了新地址，其实也不是什么大不了的事情，  因为普遍来说， 我们对DNS 解析错误容忍度 非常高，  也就是要求其 有很好的 容错性能！）！  我记得曾经有一个面试官跟我说过， DNS 就是这个星球上 最大的 分布式系统。 好像挺有道理哦！~~~

这里我们可以再次看到，P 和 C 是 直接对立的， P 发生的那一刻，C 就其实已经失去了，  除非采取某些 措施， 但是其实可以说， 不管采取什么措施 C 都是无法完全 恢复的， 从而只能是 恢复部分的 C ， 除非失去所有的A ！

所以 我们常常需要在A 和C 之间做个权衡 或者取舍，不要完美的AP，也无法满足完美CP。完美C就必然完全失去所有C，完美A就必然完全失去部分C。 可以做到的是，牺牲A 越多，保留的C 越多，反之保留A 越多，那么失去的的C 越多。 前面说的是网络分区的情况下，另外 如果是 某个节点挂掉了， 那么无论如何， 无法保证完美C 和A， 因为那个节点 上的 所有的 功能（包括A和C） 都一起完全的 失去了。

我们可以不要完美的AP 或者CP；而是根据使用的业务场景，保留完美P， 然后保留部分的 A 和 保留部分的 C。 —— 这就是所谓的 软状态！

最后， 多说一句，现在的分布式系统应用场景复杂， 功能也支持越来越多，单纯的讨论其 是AP 还是CP， 我认为意义不大了，这种分类其实意义不大 ！

参考：

https://blog.csdn.net/wireless_com/article/details/79153643