【分布式理论】CAP PACELC

文章目录一、引言二、CAP理论2.1 CAP分别指的是什么2.2 CAP 的经典表述三选二2.1 CP 系统牺牲可用性保证一致性2.2 AP 系统牺牲一致性保证可用性三、PACELC理论3.1 PACELC的由来3.2 PACELC分别指的什么一、引言在构建现代大规模、高可用的分布式系统时如何有效地管理和协调跨多个节点的数据状态始终是核心挑战之一。数据的一致性、服务的可用性以及系统对网络故障的容忍能力构成了评估分布式系统设计的关键维度。理解这些维度之间的关系及其内在权衡对于设计健壮可靠的系统至关重要。二、CAP理论2.1 CAP分别指的是什么Cconsistency 一致性即所有节点在同一时间看到的数据是一致的当一个客户端写入成功后后续所有客户端的读操作无论从哪个节点读都能读到刚刚写入的值。系统表现得像只有一个副本读写操作是原子性的。Aavailability 可用性每一个非故障节点都必须对请求做出响应成功或失败不允许超时或拒绝强调“每一个”节点而不是集群整体可用。即使部分节点故障剩余节点仍能立即处理请求允许返回旧数据但不能不响应。PPartition Tolerance 分区容错性指系统能够容忍网络分区节点间网络中断形成两个或多个互不相通的子网络网络分区是分布式系统的客观事实无法避免因此P是必须考虑的2.2 CAP 的经典表述三选二CAP 理论常说“一个分布式系统无法同时满足 C、A、P最多只能满足其中两个”。但这个表述容易引起误解——P 实际上是不能“放弃”的因为在分布式系统中网络分区一定会发生。所以更准确的表述是当网络正常时系统可以同时提供 C 和 A当网络发生分区时系统必须在 C 和 A 之间做出选择。于是有了两种典型的系统类型2.1 CP 系统牺牲可用性保证一致性当发生网络分区时系统会拒绝服务或只让部分节点提供服务以确保数据一致。例子ZooKeeper、etcd、HBase。场景对数据一致性要求极高的场景如分布式锁、选主、配置管理。2.2 AP 系统牺牲一致性保证可用性当发生网络分区时系统继续响应所有请求但节点间可能返回不一致的数据。之后通过最终一致性如异步复制、冲突解决来慢慢达成一致。例子Cassandra、Eureka、CouchDB。场景对可用性要求极高允许短暂数据不一致如社交网络、商品浏览。三、PACELC理论3.1 PACELC的由来PACELC的发展是为了解决CAP定理的一个关键局限性:它对性能或延迟没有任何规定。例如根据CAP定理如果查询在30天后返回响应可以认为数据库是可用的。显然这样的延迟对于任何实际应用都是不可接受的。Martin Kleppmann在他对CAP定理的全面批评中写道:“CAP常常被解释为证明最终一致性数据库具有比强一致性数据库更好的可用性属性;尽管这有一定道理我们表明需要更加谨慎的推理。”因此重要的是要记住CAP定理是一个简化的模型用于理解一个非常复杂的主题。PACELC是解决CAP定理这一局限性的一种尝试。CAP定理保持沉默的一个地方是:当没有网络分区时会发生什么?在没有分区的情况下分布式系统有哪些选择?3.2 PACELC分别指的什么PACELC定理规定在一个复制数据的系统中:如果存在分区P分布式系统可以在可用性和一致性之间进行权衡(即A和C;否则E当系统在没有分区的情况下正常运行时系统可以在延迟(L)和一致性©之间进行权衡。定理的前半部分(PAC)与CAP定理相同ELC是其扩展部分。整个命题是在假设通过复制来保持高可用性的情况下进行的。因此在发生故障时CAP定理仍然适用。但如果没有故障我们仍然必须考虑复制系统的一致性和延迟之间的权衡。所以PACELC中的PAC实际上就是前面提到的CAP理论其是建立在存在网络分区的情况下的若没有发生网络分区我们就使用其拓展的部分ELC看两个例子例如我们熟悉的Redis我们知道它作为分布式缓存效率是它考虑的第一因素因此它是PA/EL模式在PA/EL模式中主从之间的复制一般使用的是异步复制异步复制不会产生阻塞典型的“管杀不管埋”从而保证主服务的立即响应。而MongoDB默认配置下则是PA/EC模式MongoDB可以被视为PA/EC(默认配置):MongoDB在主/从配置中工作。在默认配置下所有的写入和读取都在主节点上执行。由于所有的复制都是异步完成的(从主节点到从节点)当主节点丢失或在少数一侧孤立时发生网络分区时有可能丢失尚未复制到从节点的数据因此在分区期间存在一致性丧失的风险。因此可以得出结论在发生网络分区的情况下MongoDB选择可用性但在其他情况下保证一致性。或者当MongoDB被配置为在大多数副本上写入并从主节点读取时它可以被归类为PC/EC。因此就会出现图中有些DB四样都支持的情况这取决于具体配置