共计 1373 个字符，预计需要花费 4 分钟才能阅读完成。
一个分布式系统外面，节点组成的网络原本应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就分布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保留，那么分区呈现后，和这个节点不连通的局部就拜访不到这个数据了。这时分区就是无奈容忍的。进步分区容忍性的方法就是一个数据项复制到多个节点上，那么呈现分区之后，这一数据项就可能散布到各个区里。容忍性就进步了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点下面的数据可能是不统一的。要保障统一，每次写操作就都要期待全副节点写胜利，而这期待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保障。为了保障一致性，更新所有节点数据所须要的工夫就越长，可用性就会升高。
作者：知乎用户
链接：https://www.zhihu.com/questio…
起源：知乎
著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。
定义
CAP 原理：分布式系统无奈同时确保一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往须要弱化对某个个性的需要。
一致性、可用性和分区容忍性的具体含意如下：
一致性（Consistency）：任何事务应该都是原子的，所有正本上的状态都是事务胜利提交后的后果，并放弃强统一；
可用性（Availability）：零碎（非失败节点）能在无限工夫内实现对操作申请的应答；
分区容忍性（Partition）：零碎中的网络可能产生分区故障（成为多个子网，甚至呈现节点上线和下线），即节点之间的通信无奈保障。而网络故障不应该影响到零碎失常服务。
CAP 原理认为，分布式系统最多只能保障三项个性中的两项个性。
比拟直观地了解，当网络可能呈现分区时候，零碎是无奈同时保障一致性和可用性的。要么，节点收到申请后因为没有失去其它节点的确认而不应答（就义可用性），要么节点只能应答非统一的后果（就义一致性）。
因为大部分时候网络被认为是牢靠的，因而零碎能够提供统一牢靠的服务；当网络不牢靠时，零碎要么就义掉一致性（少数场景下），要么就义掉可用性。
留神：网络分区是可能存在的，呈现分区状况后很可能会导致产生“脑裂”景象。
利用场景
既然 CAP 三种个性不可同时失去保障，则设计零碎时候必然要弱化对某个个性的反对。
弱化一致性
对后果一致性不敏感的利用，能够容许在新版本上线后过一段时间才最终更新胜利，期间不保障一致性。
例如网站动态页面内容、实时性较弱的查问类数据库等，简略分布式同步协定如 Gossip，以及 CouchDB、Cassandra 数据库等，都为此设计。
弱化可用性
对后果一致性很敏感的利用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。
Paxos、Raft 等共识算法，次要解决这种状况。在 Paxos 类算法中，可能存在着无奈提供可用后果的情景，同时容许多数节点离线。
弱化分区容忍性
事实中，网络分区呈现概率较小，但很难完全避免。
两阶段的提交算法，某些关系型数据库以及 ZooKeeper 次要思考了这种设计。
实际中，网络能够通过双通道等机制加强可靠性，实现高稳固的网络通信。
