分布式系统的 CAP 定理

CAP定理指出,在一个分布式系统中,对于一致性、可用性、分区容错这三个特性,不可能同时满足,而是必须有所舍弃。我们设计分布式系统时,必须在三者之间(尤其是一致性和可用性之间)有所取舍和平衡。

作者:王克锋
出处:https://kefeng.wang/2018/08/01/distributed-cap/
版权:自由转载-非商用-非衍生-保持署名,转载请标明作者和出处。

1 概述

1.1 概念

CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),是分布式系统中的一个基本定理。
它指出任何分布式系统(Distributed System)中,最多具有一致性、可用性、分区容错这三个特性中的两个。
也就是说,三个特性无法兼顾,必须有所取舍。

1.2 历史

  • 1998年,加州大学(University of California)的计算机科学家埃里克·布鲁尔(Eric Brewer)提出该原理,并于次年出版;
  • 2000年,Eric Brewer 在的分布式计算原则研讨会(Symposium on Principles of Distributed Computing)上提出该猜想;
  • 2002年,麻省理工学院(MIT)的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明,使之成为一个定理。

2 三个特性

2.0 初始状态

我们假定一个非常简易的、只有 G1/G2 两台服务器构成的分布式系统:
G1/G2 之间可以相互通信,两者都有相同的变量v,初始值都是v0。
客户端 C 与 G1/G2 都可以通信,读写操作可以从 G1/G2 中任选。

初始状态,如下图:

客户端读取,如下图:

客户端写入,如下图:

2.1 一致性(Consistence)

一致性是指,各节点的数据保证一致(每次成功写入之后,无论从哪个节点读取,都能读取到最新数据),相当于向所有节点的写操作是原子操作(要么全部失败要么全部成功)。一致性有三种策略(CAP指的是强一致性):

  • 强一致性:写操作完成后,后续的读操作都能看到最新数据;
  • 弱一致性:能容忍部分或全部都看不到最新数据;
  • 最终一致性:经过一段时间后,都能看到最新数据。

不一致的情形,写操作至G1,但未(或尚未)同步至G2,就从G2读读取。如下图:

一致的情形,写操作至G1,成功同步至G2之后,才允许进行读操作。如下图:

2.2 可用性(Availability)

可用性是指,每次向未崩溃的节点发送请求,总能保证收到响应数据(允许不是最新数据)。
参照前面“一致性”中的两种情形,可见一致性和可用性无法兼顾:

  • 若要保证一致性:则必须进行节点间数据同步,同步期间数据锁定,导致期间的读取失败或超时,破坏了可用性;
  • 若要保证可用性:则不允许节点间同步期间锁定,这又破坏了一致性。

2.3 分区容错(Partition tolerance)

分区容错是指,容许节点 G1/G2 间传递消息的差错(延迟或丢失),而不影响系统继续运行。
分布式系统中,必须满足 CAP 中的 P,此时只能在 C/A 之间作出取舍。

CAP 经常被误解为“三选二”,但实际上必须满足P,然后在 C/A 之间做出选择。

3 CAP 的证明

反证法。假设可以同时满足一致性、可用性、分区容错这三个特性,由于满足分区容错,可以切断 G1/G2 的连线,如下图:

  • 当 C 把 v1 写入 G1 后,由于可用性,G1 必须成功响应(由于 G1/G2 不通,G2 仍旧是 v0);
  • 然后,C 向 G2 读取数据,由于可用性,G2 必须成功响应,但响应的值是陈旧的 v0;
  • 可见,C 写入了 v1,但读到了 v0,没有满足一致性,可见三个特性不可能同时满足。

4 CAP 的应用

CAP 理论,被看成分布式系统(尤其是分布式存储)的理论基础。

  • 舍弃P(选择C/A):单点的传统关系型数据库 DBMS(MySQL/Oracle),但如果采用集群就必须考虑P了;
  • 舍弃A(选择C/P):是分布式系统要保证P,而且保证一致性,如 ZooKeeper / Redis / MongoDB / HBase;
  • 舍弃C(选择A/P):是分布式系统要保证P,而且保证可用性,如 CoachDB / Cassandra / DynamoDB。

对于一个分布式系统来说,CAP三者中,

  • P是基本要求,只能通过基础设施提升,无法通过降低 C/A 来提升;
  • 然后在 C/A 两者之间权衡。

一个还不错的策略是:保证可用性和分区容错,舍弃强一致性,但保证最终一致性,比如一些高并发的站点(秒杀、淘宝、12306)。最终近似于兼顾了三个特性。

5 参考资料

WikiPedia - CAP theorem
CAP理论十二年回顾:”规则”变了
An Illustrated Proof of the CAP Theorem
Gilbert and Lynch’s paper - Perspectives on the CAP Theorem

### Java分布式系统中的CAP定理解释与实现 #### CAP定理概述 在设计分布式系统时,CAP定理是一个重要的概念。该定理指出,在一个分布式计算环境中,无法同时完全满足一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance),最多只能三者取其二[^3]。 - **一致性 (C)**:每次读操作都能获取到最新的写入数据或返回错误。 - **可用性 (A)**:每个请求都会收到响应,而不必担心失败的情况;但是不保证获得的数据是最新的。 - **分区容忍性 (P)**:即使网络发生分割,系统仍然可以继续运作并处理部分节点之间的通信中断。 对于大多数现代互联网应用而言,由于网络环境复杂多变,通常会选择牺牲强一致性的严格要求来换取更高的可用性和更好的分区容忍能力。 #### 实现案例分析 考虑到实际应用场景的需求差异很大,不同的项目可能会有不同的侧重点: - 如果应用程序非常重视用户体验,则可能更倾向于选择AP模型——即允许一定程度上的最终一致性以确保服务始终处于在线状态; - 对于金融交易类业务来说,因为涉及到资金安全等问题,往往优先考虑CP模式下的高可靠性和精确度。 具体到Java技术栈下开发的分布式系统里,可以通过调整配置参数以及选用合适的技术框架来进行优化设置。例如使用Apache ZooKeeper作为协调服务器可以帮助达成共识从而提高系统的整体可靠性;而像Eureka这样的注册中心则有助于增强微服务体系结构内的灵活性和支持动态发现机制。 ```java // 使用ZooKeeper实现简单的Leader选举算法 public class LeaderElection { private static final String ZK_ADDRESS = "localhost:2181"; public void electLeader() throws Exception{ CuratorFramework client = CuratorFrameworkFactory.newClient(ZK_ADDRESS, new ExponentialBackoffRetry(1000, 3)); client.start(); InterProcessMutex lock = new InterProcessMutex(client,"/leader"); try { if(lock.acquire()){ System.out.println(Thread.currentThread().getName()+" becomes leader."); } } finally { lock.release(); client.close(); } } } ``` 上述代码展示了如何利用Curator库配合Zookeeper完成一次基本的领导者选举过程,这正是为了保障某些场景下一组进程间的一致行为所采取的一种策略之一。 #### 技术选型建议 当面对具体的工程实践时,应该基于业务特性做出合理的选择: - 当需要频繁更新共享资源且不允许任何版本冲突的情况下,应偏向采用支持事务ACID特性的数据库产品如MySQL Cluster等; - 若追求极致性能表现并且能够接受较弱形式的一致性约束的话,NoSQL家族成员Redis、MongoDB将是不错的选择; - 面向大规模集群部署需求的企业级解决方案中,HBase凭借其出色的水平扩展能力和良好的社区生态同样值得推荐尝试。 通过以上讨论可以看出,在构建Java分布式信息系统过程中充分理解并灵活运用CAP原则至关重要。它不仅影响着底层基础设施的设计决策,同时也决定了上层逻辑层面的服务质量标准。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值