从⼊门到精通！java⾯向对象程序设计第三版课后题答案
什么是 CAP
CAP 定理最初是由加州⼤学伯克利分校的计算机科学家埃⾥克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的⼀个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，⿇省理⼯学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了CAP 定理的证明，让它成为分布式系统领域公认的⼀个定理。
CAP 定理指出了，在⼀个跨区域⽹络连接，共享数据的分布式系统中，⼀致性（Consistency），可⽤性（Availability）和分区容错性（Partition Tolerance） 这三个约束属性最终只能同时满⾜⼆个。
下⾯是关于这三个属性的简单描述：
⼀致性：客户端进⾏读操作得到的数据永远是最近⼀次写⼊的数据，要求了对数据读写的强⼀致性。
可⽤性：客户端的请求在限定时间内总能从⾮故障的系统节点得到正常的响应，其中不能有超时，不能出错如 502之类。
分区容错性：就是出现⽹络分区现象，即节点间⽆法正常通信，数据同步出现延时等情况时，系统仍能继续提供服务。
需要注意的是，CAP 描述了⼀个常规的分布式系统场景：有⽹络连接，且数据跨节点进⾏共享。如果在整个系统中，数据只有⼀份，并且其他节点没有对应的副本，也不需要进⾏跨节点的数据共享，这样分布式系统就不是 CAP 关⼼的对象了，也谈不上结合 CAP 定理去设计和实施。
深⼊认识 CAPjava入门课件
了解 CAP 基本概念之后，我们再来分别对 C，A，P 三个属性进⼀步学习下，加深对 CAP 的理解。
C：⼀致性
这⾥的⼀致性从不同⾓度有着各⾃的描述⽅式，在分布式系统中表现是每个节点的数据是相同；⽽对于客户端，表现是读操作所得到的结果永远是最新写⼊的。其中需要明确的是，对于分布式系统节点来说，是可能出现某个时刻拥有不同的数据的情况：如果在某个节点执⾏原⼦性操作时，对于执⾏过程中的节点数据跟其他节点就并不完全⼀致，只有原⼦性操作执⾏完成后，节点的数据才会继续保持
同步。⽐如常见的事务操作，只有事务提交后，客户端才能读取到事务写⼊的数据，失败则回滚为旧的数据，不会出现读取事务中间写⼊数据的情况。
⼀致性要求了在分布式环境下的操作要就像在单机上完成的⼀样，当客户端发起写请求时，收到写请求的节点会及时响应，并将更新的数据同步到另⼀个节点，保证数据⼀致性。具体的⼯作流程，如下所⽰：
1. 客户端向节点 1 发送写操作，将数据 X 更新为 1 ，
2. 更新操作成功，系统将更新的数据从节点 1 同步到节点 2，将节点 2 的旧数据 X 也更新为 1。
3. 客户端再向节点 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 定理所认识的局限，设计出符合⾃⾝业务场景的分布式系统才是重中之重。
分享
这次⾯试我也做了⼀些总结，确实还有很多要学的东西。相关⾯试题也做了整理，可以分享给⼤家，了解⼀下⾯试真题，想进⼤⼚的或者想跳槽的⼩伙伴不妨好好利⽤时间来学习。学习的脚步⼀定不能停⽌！
，整理出的内容⼤概如下：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。