神一样的CAP理论被应用在何方？ _CAP理论

【51CTO.com原创稿件】对于开发或设计分布式系统的架构师工程师来说， CAP 是必须要掌握的理论。

文章插图

【神一样的CAP理论被应用在何方？】图片来自 Pexels
But：这个文章的重点并不是讨论 CAP 理论和细节，重点是说说 CAP 在微服务中的开发怎么起到一个指引作用，会通过几个微服务开发的例子说明，尽量的去贴近开发。
CAP 定理又被称为布鲁尔定理，是加州大学计算机科学家埃里克·布鲁尔提出来的猜想，后来被证明成为分布式计算领域公认的定理。
不过布鲁尔在出来 CAP 的时候并没有对 CAP 三者(Consistency ， Availability ， Partition tolerance)进行详细的定义，所以在网上也出现了不少对 CAP 不同解读的声音。
CAP 定理
CAP 定理在发展中存在过两个版本，我们以第二个版本为准：
在一个分布式系统中(指互相连接并共享数据的节点集合)中，当涉及到读写操作时，只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个，另外一个必须被牺牲。

文章插图

这个版本的 CAP 理论在探讨分布式系统，更加强调两点是互联和共享数据，其实也是理清楚了第一个版本中三选二的一些缺陷。
分布式系统不一定都存在互联和共享数据，例如 Memcached 集群相互间就没有存在连接和共享数据。
所以 Memcached 集群这类的分布式系统并不在 CAP 理论讨论的范围，而像 MySQL 集群就是互联和数据共享复制，因此 MySQL 集群是属于 CAP 理论讨论的对象。
一致性(Consistency)
一致性意思就是写操作之后进行读操作无论在哪个节点都需要返回写操作的值。
可用性(Availability)
非故障的节点在合理的时间内返回合理的响应。
分区容错性(Partition Tolerance)
当网络出现分区后，系统依然能够继续旅行社职责。
在分布式的环境下，网络无法做到 100% 可靠，有可能出现故障，因此分区是一个必须的选项。
如果选择了 CA 而放弃了 P ，若发生分区现象，为了保证 C ，系统需要禁止写入，此时就与 A 发生冲突;如果是为了保证 A ，则会出现正常的分区可以写入数据，有故障的分区不能写入数据，则与 C 就冲突了。
因此分布式系统理论上不可能选择 CA 架构，而必须选择 CP 或 AP 架构。
分布式事务 BASE 理论
BASE 理论是对 CAP 的延伸和补充，是对 CAP 中的 AP 方案的一个补充，即使在选择 AP 方案的情况下，如何更好的最终达到 C 。
BASE 是基本可用，柔性状态，最终一致性三个短语的缩写，核心的思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性。
CAP 在服务中实际的应用例子
理解貌似讲多了，项目的 CAP 可以参考下李运华的《从零开始学架构》的书里面的 21 ， 22 章，比较详细的描绘了 CAP 的理论细节和 CAP 的版本演化过程。
这里着重讲解的是神一样的 CAP 在我们的微服务中怎么去指导和应用起来，大概会举几个平时常见的例子。