不一样的CAP，拒绝网上抄抄抄

接触CAP和BASE理论很久了，也看了很多资料，每次看了之后都觉得不对劲，网上绝大多数资料包括很多书中就会copy来copy去（能有点出息不）。
看了之后脑子里面疑问：CAP，BASE和我们平时的应用有什么关系？ 倒是落个地呀，举几个例子给我看看呀。哎，网上其它的都是渣渣，看了之后都不满意，自己上手写一篇。
以下内容都是我个人的理解，如果大家有什么不同的意见欢迎一起探讨。

开篇复习CAP理论的文字定义

CAP英文：帽子，其实和帽子一点关系都没有，是三个单词的首字母和一起得出的CAP。三个字母分别是：

C：Consistency，这个一致性和ACID理论的Consistency不一样，这里的一致性指的是分布式系统的一致性：每个客户端请求分布式系统的所有节点都能获取一致的数据（一样的数据），比如客户端发出读请求，读请求不管到了哪一个节点，都必须返回一样的数据给客户端；ACID理论的一致性指的是事务之中的一致性，更详细内容请看附录1。

A：Availability，可用性，每个客户端请求每个节点，都要有响应，或者直接全部不响应。

P：Partition tolerance，分区可用性，要想理解分区可用就得先理解什么是分区：分区指的是网络分区，即网络延时严重（这个是经常发生的，笔者也遇到）、光纤被挖断、机房网线被老鼠坑断等原因发生了网络隔离。理解了分区才能理解什么是分区可用，分区可用就是发生了网络分区之后，不敢内部节点通信如何（数据同步问题），客户端请求每个节点，都能提供一致性、可用性的服务，或者全部网络都有问题直接不提供服务。

京东技术部首席架构师何小锋有句话，我非常同意：任何事情如果你能有一句话说明它，你就是真正的掌握它了。

我对CAP理论的一句话说明：CAP理论是分布式系统架构设计的时候一个基础参考理论，它的模型是基础参考模型。

CAP三选二

为什么必须三选二？网上找结论去，推导过程一套一套的，这里直接使用结论：CAP理论只能三选二（数学的组合模式）：CA，CP，AP。

CA，放弃了P。网络上一堆人说必须选在P，却没说为什么必须选择P？真的一定要选择P吗？笔者的理解是这句话也对也不对（附录2）。没选择P的中间件学计算机的人肯定都使用过：关系型数据库（MySQL，Oracle、SQLServer等），其实连我只写文件，不写数据库都算是选择了CA放弃P。**为什么是放弃了P呢？答案是：关系型数据库、文件都是没有网络交互，没有网络如何来网络分区，当然这里不考虑关系型数据主从复制、分库分表的情况。**这里也许有读者说：Redis的单机，Elasticsearch单机难道也是放弃了P，是CA？答案是肯定的。

CP：放弃了A。放弃了高可用，选择了CP，上面的问题：分布式系统为什么必须选择P还没正面回答，不过部分读者应该有答案了，我的答案是：分布式系统有网络通信，有网络通信就有网络延时，网络延时一旦严重就会有网络分区的情况出现（跨机房玩一下，出现的概率很大），所以在设计分布式系统的时候必须要 考虑网络延时。

然后回到我们的正题，选择一致性和分区容错，这里的一致性是分布式系统的一致性哦。现实中我们使用的Redis的Raft算法也是解决这个问题的。Redis的Cluster模式就是选择了CP。

AP：放弃了一致性，过去笔者也觉得这个不怎么碰到吧，但是大错特错。我们碰到最多的就是AP。我说一个，如果读者做个大系统应该都接触过：分库分表。

我贴出网上一张图，这张图显示中间件在CAP的分布，注意注意：这张图不是完全正确，是在这些中间件指定的模式下正确的。程序袁小黑是我的公众号，欢迎关注。

最后提一点：大家一定一定要去infoq上搜一下：CAP理论十二年回顾："规则”变了，这篇文章非常经典，分布式系统学习必看。

CAP理论的使用

拒绝任何说概念不落地的行为，那些都是吹牛。

分布式系统，分布式就是需要网络的，需要网络就需要考虑网络延时，网络延时严重而引起的网络分区就是我们必须选择的。

那么我们设计系统的时候，必须考虑P。那么就需要根据自己的需求选择需要执行A还是C。

从来没人说过CAP实现需要什么，下面是我的个人总结，欢迎来捶：

1. A，想要支持A，就是出现网络分区也一定要响应，或者你宕机了但是我的数据也不会丢，数据一定正常，这面需要往顺序文件读写、redo日志、undo日志、关系型数据库这方面思考。
2. C，想要支持C，分布式一致性算法有很多，从理论的2PC、3PC到落地的Raft、ZAB，如果是集群中有恶意节点就考虑PBFT算法、PoW算法。这里有一个注意点：比如Raft算法是一种共识算法，实现一致性需要客户端配合，一致性也可以分级别，这个关系到后面的BASE理论，这不展开讨论。
3. P，想要放弃P就不是建设分布式系统了去掉网络交互就是放弃了P。这里特意提一下RocketMQ，RocketMQ的容错机制是通过客户端的重发来/重新消费来实现，broker之间是没有交互的，如果一台broker宕机是不会影响其它服务的，这种情况也是某种意义上实现了P。

最后提一句：CAP理论并不是真的一定是三选二，比如Redis的Sentinel提供了高可用方案，但是就带来了限制：Sentinel不能适用于集群。Redis集群通过分槽（一种另类的分库分表）实现了另类的AP，但是它得通过客户端支持。Redis通过Raft算法实现了主从的一致性，这点和它通过客户端实现特殊的AP并不冲突，但是Redis就是满足CAP所有的条件了吗？并不是！Redis的集群模式还是选在CP，如果出现网络分区，Raft算法会让分区的小集群拒绝请求，出现不可用。

以上就是我对CAP理解的全部内容，有任何问题请留言探讨。

最后来一句：根据自己的项目需求参考CAP理论设计自己的架构，而不是盲目听信网上的观点，网上很多观点是错的。

附录

附录1

ACID的一致性，我们在操作数据库多张表的时候有很多数据是有相关联的业务意义的，保存这些业务意义相关连的业务意义的数据一致性、完整性是ACID一致性需要做的事情。这个一致性和分布式系统的一致性不一样，请特别注意。

附录2

笔者曾经接触过一个保险项目，多个工程共享一个数据库，不存在分区问题。个人理解是：根据自己的项目需求参考CAP理论设计自己的架构，而不是盲目听信网上的观点，网上很多观点是错的。