本文主要是介绍CAP为什么不能兼得，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
原文链接：石匠的Blog
什么是CAP
所谓CAP原则，是指在分布式系统中Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）三者不能同时得到。
- 一致性：在分布式系统中，一个数据存在多个副本的情况下，各个副本的值是否一致。
- 可用性：当系统收到一个请求后，在一定时间之内，总是可以反馈一个结果给用户，无论成功还是失败。
- 分区容错性：当网络出现分割后，系统仍然可以提供服务。
CAP拆解
在当今的基础网络中，存在不同的网络运营商，不同地域，不同的骨干线路等情况。比如在CDN厂商会按照运营商和地域将整个网络分成不同的“覆盖”，每个“覆盖”可以作为一个独立的服务节点提供覆盖内的用户访问。为了进行细分拆解，可以将“覆盖”看做分区隔离性中的“区”;
CA
假设不考虑分区（P）的情况下，只有一个分区（副本），副本的一致性自不必说，自然是一致的；可用性方面，一个节点的写入不需要同步到其他节点，可以高效完成。如果增加多个分区（提高分区容错性），数据的写入需要同步到多个节点（强一致性，所有节点同步成功后再返回用户），增加了同步时间和同步失败的可能性，降低了可用性；如果采用弱一致性，即写入操作在主节点成功后即返回用户结果，再通过异步方式同步到多个分区，那么会增加同步失败和数据丢失的几率，降低了一致性。
CP
假设不考虑可用性（A）的情况下，多个分区之间可以采用强一致性的机制，保证数据的高度一致性（要么都成功要么都失败）。比如某个分区出现了故障或者分隔，分区没有了响应，由于放弃了可用性，所以可以无限等待并不断重试直到网络恢复，分区可用后将副本数据同步到所有节点。
AP
假设不考虑一致性（C)的情况下，多个分区和副本可以提供高可用性。分区越多，用户越能就近访问，提供响应速度；放弃了一致性后，副本的写入操作可以写入主节点成功后即可返回成功，获得搞可用性，然后通过异步的方式将副本同步到多个分区节点上。
由此可见，CAP三者确实不能同时满足，只能根据具体的分布式业务场景做取舍和折中；比如银行系统可以牺牲可用性从而保障CP，响应慢一点（甚至网络故障暂停服务）总比账户资金出现错误更优。而很多提供互联网服务可以一定程度牺牲一致性来保障AP，因为互联网竞争激烈，追求的是用户体验和效率，希望用户随时随地能够高效获得服务，而一致性则通过一系列的措施做到最终一致性即可。
这篇关于CAP为什么不能兼得的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
