《区块链技术指南》笔记-CAP原理

定义

分布式计算系统不可能同时确保一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往需要弱化对某个特性的保证。

• 一致性（Consistency）：任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果，注意这里指的是强一致性；
• 可用性（Availability）：在有限时间内，任何非失败节点都能应答请求；
• 分区容忍性（Partition）：网络可能发生分区，即节点之间的通信不可保障。

比较直观地理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其他人的确认就不应答，要么节点只能应答费一致的结果。
好在大部分时候网络都被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（大部分时候都是如此），要么牺牲掉可用性。

应用场景

既然CAP不可同时满足，则设计系统时候必然要弱化对某个特性的支持。

弱化一致性

对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才更新成功，期间不保证一致性。
例如网站静态页面内容、实时性较弱的查询类数据库等，CouchDB、Cassandra等为此设计。

弱化可用性

对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis等为此设计。
Paxos、Raft等算法，主要处理这种情况。

弱化分区容忍性

现实中，网络分区出现概率较小，但较难避免。某些关系型数据库、ZooKeeper即为此设计。
实践中，网络通过双通道机制增强可靠性，达到高稳定性的网络通信。