CAP理论是讨论分布式系统设计优劣时的老生常谈，最近学习极客时间上周志明的软件架构课，对几个之前以为通透了的理论进行了重新理解与消化，并对过去的错误考虑进行了勘误，有必要重新梳理下。

CAP理论是我接触分布式设计过程中最初遇到的理论之一，最初去了解相关理论的出发点是为了做职级晋升答辩。不同于日常业务开发的关注点为系统的快速设计与落地，答辩更关注对具体问题的思考是否足够科学，推理是否缜密，能否契合具体的业务场景，用相对静态的理论来承接场景。可以说一开始是很不适应的，又经过了1、2年，走到了另一个极端，各种名词不离口（可用性、一致性、性能、安全性、ACID、BASE、鲁棒），但并没有真正的指导开发，也就是说一套做一套，更甚者说了不做，先做再往理论上靠的懒惰行为也有。19、20年以来逐渐找到了以解决问题为导向，行动符合科学理论的感觉，也就是摸索知行合一。

CAP（帽子）理论，2000年eric brewer提出，2002年由2位数学家证实的理论，即没有任何分布式存储系统可以同时满足一致性、可用性与分区容错性，而分区容错性不可避免，设计者需要在一致性与可用性上做好取舍。

可以说任何真理都是相对真理，都要被前提条件约束，而这个约束条件越宽松，那么理论能覆盖的范围也就越大，从某种意义上理论的科学价值也更高些。CAP理论生效的大前提是：分布式数据共享系统，解决的问题是：在上述前提下，发生网络分区时，设计者如何进行取舍（trade off)。

3个字母分别代表：一致性（consistency），可用性（Availability），分区容错性（Partition Tolerant）。一般到这个时候都要讲一下这仨属性分别是什么，而通常错误也会出现在对这3个名词的定义边界上。

首先说P：分区容错性是指在一个分布式系统（一定有2个或以上的node）中，node间因为要通过网络通信，因此一定会出现node间无法通信的情况，而在以上情况下：a. 系统要可以继续提供服务；b. 当网络恢复时，系统也能够优雅恢复；从当前开发经验上可以很快得出结论，P在分布式系统里是一定会出现的：网络链路不可靠，node本身也会出现故障，导致从系统层面上看，node之间的网络通信不可达；

然后说A：在cap理论里的A指的是，在网络分区发生时，所有的数据节点是否都能提供读、写服务，并保证在一个承诺的时间内返回。这里的误区就是，一说cp模型系统，是不是就可以接受单节点挂掉不可用，实际上cap理论里讨论的可用性，并不是我们常见的，站在分布式系统外，观测整个系统主动停机+被动停机时间的可用性。这个可用性，只关注在发生网络分区时，我们是否保证每个节点仍旧参与系统功能的读写上；

最后说C：这个一致性与ACID里追求的强一致性显然不是一个东西（所以说命名害死人），cap中的一致性也考虑的是在网络分区发生时，是否保证集群中每个节点都返回系统中最新成功写入的数据。个人理解就是，选择保证返回最实时写入的数据，而不采用历史副本。

 

所以从这个角度看，cap理论只能解释相对小的case，比如某个多node部署的中间件。关注在分区发生时，各节点是直接返回历史副本保证可用性，还是需要等待集群各节点协商达成一致后再返回数据（通常是选主：paxos，raft）；如果是纯吞吐型系统，就别提cap了（比如nginx dns lb集群）；在整个大的框架中谈论cap，也并不合适（因为大型系统的复杂度高，在设计过程中会同时应用cp、ap的方案，全局谈cap是没意义的）。

 

因此盘一下常见的cp中间件：zk，etcd，特点是节点存储的数据在各个节点上读取一致，在网络分区情况下，产生脑裂+重新选举，这时只有持有集群一半以上的子网才能提供服务，其他node无法提供服务。也就是宁可让客户端等，也不能给予非当前生效数据；ca考量的中间件多，整体体现为流量思维：MySQL的主从，redis的主从，Kafka等，在高流量系统的中间件中，通常采用历史数据副本的方式，应对网络分区->恢复的过程，保持所有node都可用，调用的client端就不会有感知。

额外提一嘴实现ca的系统，这种设计也可以说有，但不在分布式架构讨论的范畴里。服务完全共享通信内存，就可以不考虑分区问题，但这也将系统退化为了单点。

 

总结看，cap理论是分布式存储系统在网络分区发生时，进行一致性与可用性tradeoff的考量，可以说并不是放在分布式设计世界里到处都能应用的理论。我们经常做的cp、ap选择，是从业务实际需求出发，没有单纯的优劣可言。而单/部分节点宕机情况下服务的可用性是那种方案下都应保障的， 不要放在cap理论框架下讨论。文章条理性不强，但大抵能讲明白这个单纯的理论，那就有一定的意义吧。