🧭
🧭
🧭
🧭
区块链技术指南
搜索文档…
🧭
🧭
🧭
🧭
区块链技术指南
前言
修订记录
如何贡献
区块链的诞生
核心技术概览
典型应用场景
分布式系统核心技术
一致性问题
共识算法
FLP 不可能原理
CAP 原理
ACID 原则与多阶段提交
Paxos 算法与 Raft 算法
拜占庭问题与算法
可靠性指标
本章小结
密码学与安全技术
比特币 —— 初露锋芒的区块链
以太坊 —— 挣脱加密货币的枷锁
超级账本 —— 面向企业的分布式账本
Fabric 安装与部署
智能合约开发
Fabric 架构与设计
区块链服务平台设计
性能与评测
附录
由
GitBook
提供支持
CAP 原理
CAP 原理最早出现在 2000 年,由加州大学伯克利分校的 Eric Brewer 教授在 ACM 组织的 Principles of Distributed Computing(PODC)研讨会上提出的猜想。两年后,麻省理工学院的 Nancy Lynch 等学者进行了理论证明。
该原理被认为是分布式系统领域的重要原理之一,深刻影响了分布式计算与系统设计的发展。
定义
CAP 原理
:分布式系统无法同时确保一致性(Consistency)、可用性(Availability)和分区容忍性(Partition),设计中往往需要弱化对某个特性的需求。
一致性、可用性和分区容忍性的具体含义如下:
一致性(Consistency):任何事务应该都是原子的,所有副本上的状态都是事务成功提交后的结果,并保持强一致;
可用性(Availability):系统(非失败节点)能在有限时间内完成对操作请求的应答;
分区容忍性(Partition):系统中的网络可能发生分区故障(成为多个子网,甚至出现节点上线和下线),即节点之间的通信无法保障。而网络故障不应该影响到系统正常服务。
CAP 原理认为,分布式系统最多只能保证三项特性中的两项特性。
比较直观地理解,当网络可能出现分区时候,系统是无法同时保证一致性和可用性的。要么,节点收到请求后因为没有得到其它节点的确认而不应答(牺牲可用性),要么节点只能应答非一致的结果(牺牲一致性)。
由于大部分时候网络被认为是可靠的,因此系统可以提供一致可靠的服务;当网络不可靠时,系统要么牺牲掉一致性(多数场景下),要么牺牲掉可用性。
注意:网络分区是可能存在的,出现分区情况后很可能会导致发生“脑裂”现象。
应用场景
既然 CAP 三种特性不可同时得到保障,则设计系统时候必然要弱化对某个特性的支持。
弱化一致性
对结果一致性不敏感的应用,可以允许在新版本上线后过一段时间才最终更新成功,期间不保证一致性。
例如网站静态页面内容、实时性较弱的查询类数据库等,简单分布式同步协议如 Gossip,以及 CouchDB、Cassandra 数据库等,都为此设计。
弱化可用性
对结果一致性很敏感的应用,例如银行取款机,当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。
Paxos、Raft 等共识算法,主要处理这种情况。在 Paxos 类算法中,可能存在着无法提供可用结果的情形,同时允许少数节点离线。
弱化分区容忍性
现实中,网络分区出现概率较小,但很难完全避免。
两阶段的提交算法,某些关系型数据库以及 ZooKeeper 主要考虑了这种设计。
实践中,网络可以通过双通道等机制增强可靠性,实现高稳定的网络通信。
以前
FLP 不可能原理
下一个
ACID 原则与多阶段提交
最近更新
4mo ago
复制链接
在 GitHub 上编辑
内容
定义
应用场景
弱化一致性
弱化可用性
弱化分区容忍性