面对可能呈现的网络提早，不可预估的申请流量等状况，设计一个分布式系统，咱们通常围绕零碎高可用，数据一致性的指标去布局和实现，想要齐全实现这个指标，却并非易事。由此，分布式系统畛域诞生了一个根本定理，即 CAP 定理，用于领导分布式系统的设计，从零碎高可用，数据一致性，网络容错三个角度将分布式系统的个性抽成一个分区容错一致性模型。这样一来，让零碎设计者只需依据业务场景特点，进行衡量设计适宜业务场景的分区容错一致性模型即可，很大水平简化了分布式系统设计的难度。
也因而，CAP 定理是架构师所必须要把握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，咱们就一起学习下 CAP 定理吧。
什么是 CAP
CAP 定理最后是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜测，也因而被叫做布鲁尔定理。起初在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证实，让它成为分布式系统畛域公认的一个定理。
CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）这三个束缚属性最终只能同时满足二个。
上面是对于这三个属性的简略形容：
- 一致性：客户端进行读操作失去的数据永远是最近一次写入的数据，要求了对数据读写的强一致性。
- 可用性：客户端的申请在限定工夫内总能从非故障的零碎节点失去失常的响应，其中不能有超时，不能出错如 502 之类。
- 分区容错性：就是呈现网络分区景象，即节点间无奈失常通信，数据同步呈现延时等状况时，零碎仍能持续提供服务。
须要留神的是，CAP 形容了一个惯例的分布式系统场景：有网络连接，且数据跨节点进行共享。如果在整个零碎中，数据只有一份，并且其余节点没有对应的正本，也不须要进行跨节点的数据共享，这样分布式系统就不是 CAP 关怀的对象了，也谈不上联合 CAP 定理去设计和施行。
深刻意识 CAP
理解 CAP 基本概念之后，咱们再来别离对 C，A，P 三个属性进一步学习下，加深对 CAP 的了解。
C：一致性
这里的一致性从不同角度有着各自的形容形式，在分布式系统中体现是每个节点的数据是雷同；而对于客户端，体现是读操作所失去的后果永远是最新写入的。其中须要明确的是，对于分布式系统节点来说，是可能呈现某个时刻领有不同的数据的状况：如果在某个节点执行原子性操作时，对于执行过程中的节点数据跟其余节点就并不完全一致，只有原子性操作执行实现后，节点的数据才会持续放弃同步。比方常见的事务操作，只有事务提交后，客户端能力读取到事务写入的数据，失败则回滚为旧的数据，不会呈现读取事务两头写入数据的状况。
一致性要求了在分布式环境下的操作要就像在单机上实现的一样，当客户端发动写申请时，收到写申请的节点会及时响应，并将更新的数据同步到另一个节点，保证数据一致性。具体的工作流程，如下所示：
- 客户端向节点 1 发送写操作，将数据 X 更新为 1，
- 更新操作胜利，零碎将更新的数据从节点 1 同步到节点 2，将节点 2 的旧数据 X 也更新为 1。
- 客户端再向节点 2 发送读操作获取数据 X 时，就会失去 X 最新的值：1。
一致性强调了数据的强统一，这一点要求对于一些零碎能够说是非常重要的。比方电商零碎的库存扣减，金融零碎的转账扣款等场景，任何呈现一致性的问题，都可能会造成很重大的结果。
A：可用性
介绍完一致性，再来看下可用性，尽管可用性概念绝对简略，但重要水平跟一致性一样。要让零碎满足可用性，就是要保障无论除了所有节点呈现故障的状况外，零碎都能返回无效的响应，容许响应给客户端是旧的数据，但不能呈现响应失败，超时的状况。
可用性强调的是服务可用，但不保证数据的正确性。用一个简略的例子来形容分布式系统的可用性如下：容许客户端向节点 1 或者节点 2 发动读操作，当其中某一个节点故障了，不论节点间数据是否统一，只有有节点服务能收到申请，就响应 X 的值，这样就阐明这两个节点服务是满足可用性。
在可用性的形容，还值得一提的是对于什么算无效的响应。要返回无效的响应，不能超时，也不能出错，后果不肯定是正确的，比方返回了旧数据，然而客户端接管到后是能进行失常业务解决的。
P：分区容错性
讲完 C 和 A 之后，最初再讲一下 P：分区容错性。因为分布式系统多个节点往往部署在多个网络环境下进行互相通信，就不免呈现一些网络故障，如网络丢包，网络音讯提早，网络中断等状况，会导致节点间的通信呈现问题，数据同步操作无奈实现，分区容错性就要求了零碎即便在网络分区呈现的状况下，能仍持续对客户端提供服务。
因为分布式系统与单机不同，它波及到了多节点间的通信和数据交互，防止不了网络问题，如果没有分区容错性，就意味着零碎不容许呈现节点间的通信呈现任何谬误，谬误就意味着零碎不可用，这在绝大数零碎中无奈承受的。因而对节点间的分区故障容错是必须要思考的，也是 CAP 定理中分区容错性通常首先要保障的起因。
如何利用 CAP 定理
理解完 CAP 定理的一致性（C），可用性（A）和分区容错性（P）之后，咱们再来看下如何应用这个定理。CAP 定理指明了 C，A，P 三个属性无奈同时满足，而在必有网络交互和数据同步的状况下，就肯定会有提早和数据失落的状况，对于这种状况咱们又必须承受且保证系统不能挂掉。所以分区容错性是必须要保障的，剩下的就是在一致性（C）和可用性（A）之间做抉择了。抉择了一致性，保证数据正确性，但也象征零碎可能存在不可用的状况；而抉择可用性，保障服务的高可用，但也象征数据可能呈现不一致性的状况。接下来就探讨下利用采纳 CP 架构，AP 架构所各自的特点，以及如何依据不同的分布式场景抉择适宜的架构策略。
CP
对于 CP 架构的分布式系统来说，为了保障一致性，当呈现网络分区后，如果节点 1 上数据 X 曾经更新为 2，但因为节点 间数据同步的通道曾经中断，节点 1 数据无奈同步到节点 2，节点 2 上的数据 X 还是 1。此时如果客户端拜访节点 2 的数据 X，节点 2 就须要返回谬误，提醒零碎产生了谬误，直到节点间的数据放弃同步。当然这样的解决形式显著违反了可用性的要求，因而在 CAP 定理只能满足 CP。
如果一个分布式场景须要很强的一致性，或者能容忍零碎长时间无响应然而数据要保持一致的状况，就比拟适宜应用 CP 架构设计对应的分布式系统。这样的零碎一旦产生网络分区会导致数据无奈同步状况，就要就义零碎的可用性，直到节点数据达到统一后再响应。在开源社区中采纳 CP 架构的利用不少，比方 Redis，HBase，MongoDB，ZooKeeper，Etcd，Consul 等都是放弃了肯定可用性而抉择 CP 属性。
AP
如果采纳 AP 架构设计的分布式系统，为了保障可用性，当网络分区产生后，同样节点 1 上数据 X 曾经更新为 2，但因为节点间数据同步的通道曾经中断，节点 1 数据无奈同步到节点 2，节点 2 上的数据 X 还是 1。这是客户端拜访节点 2 获取数据 X 时，收到是失常的响应，旧数据 X = 1，而实际上以后最新的数据 X 曾经是 2 了，这里就不满足一致性的要求了，因而在 CAP 定理只能满足 AP。
同样适宜 AP 的场景有很多，比方一些查问零碎，电商零碎的商品查问等，大多数为了保证系统的可用性，而就义肯定的数据一致性，这样也保障了用户体验，在开源界中采纳 AP 模型的典型利用有 Eurka，Cassandra。
必须三选二吗
提到了 CAP 定理，大多数人都认为无论什么状况，分布式系统只能在 C 和 A 中抉择一个。但这里的前提是零碎产生了网络分区状况，如果零碎没有产生网络分区的状况，也就是说 P 不存在的时候，咱们就没有必要放弃 C 或者 A，因而进行架构设计时也应该思考没有分区状况下如何保障 CA。除此之外，一个分布式系统不肯定只能从 AP 与 CP 中做抉择，外部不同模块所应答的场景也不同，齐全有可能是一个模块采纳 AP 架构，另一个模块采纳 CP 架构。作为优良的架构师，不应该受到大多数人对 CAP 定理所意识的局限，设计出合乎本身业务场景的分布式系统才是重中之重。
总结
本文次要理解和意识 CAP 定理，以及每个 C，A，P 的含意，以及 CAP 定理的利用。把握 CAP 定理，对架构师来说十分重要。因为对于分布式系统来说，网络故障在劫难逃，如何在呈现网络故障的时候，维持零碎依照失常的行为逻辑运行就显得尤为重要。一个合格的架构师须要是能结合实际的业务场景和具体需要，基于 CAP 定理来进行衡量和设计可用且稳固的分布式系统。
参考资料
- CAP theorem – Wikipedia
https://en.wikipedia.org/wiki… - 想成为架构师，你必须晓得 CAP 实践
https://time.geekbang.org/col… - CAP 定理：三选二，架构师必须学会的取舍
https://time.geekbang.org/col…
本文由博客一文多发平台 OpenWrite 公布！