【架构】CAP 定理 P 代表什么含义

本文深入解析了CAP定理,阐述了分布式系统中一致性、可用性和分区容错性的权衡,以及Eureka、Zookeeper和Consul在实现框架中的对比。理解这些概念有助于设计高效可靠的分布式应用架构。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

CAP 定理的定义是指在分布式系统中三者只能满足其二(前提是出现分区问题,正常情况下CAP都能满足)

什么是 CAP 定理(CAP theorem)

在理论计算机科学中,CAP 定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:

  • 一致性(Consistency) (等同于所有节点访问同一份最新的数据副本)
  • 可用性(Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
  • 分区容错性(Partition tolerance)(系统出现分区问题,节点间因为网络延迟或故障不可通信,必须在 C 和 A 之间做出选择。)

分区容错性(Partition tolerance)

分区现象:即多个分区之间无法通信,相互隔离(如网络不通导致)

分区容错:多个分区无法通信后,整个系统还可提供服务(如果选择CP,则必须等待剩余不存在分区问题的节点间重新达成一致,比如故障节点为主节点,需要在剩余节点重新选举主节点)

理解 CAP 理论的最简单方式是想象两个节点间无法通信,对客户端操作来说:

1、允许两个节点间数据不一致,即丧失了 C 性质。(两个节点为主从同步,客户端往其中一个节点写数据,无法同步到另一个节点)

2、如果为了保证数据一致性,会返回客户端,系统不可用,即丧失了 A 性质。

3、除非两个节点可以互相通信,才能既保证 C 又保证 A。(两个节点可以通信,表示分区可用)

  • P 指的是分区容错性,分区现象产生后需要容错,容错是指在 A 与 C 之间选择。如果分布式系统没有分区现象(没有出现节点间网络通信问题) ,就可以同时满足CAP。
  • 需要在A、C之间选择的前提是得有分区情况存在

几个常用的 CAP 框架对比

框架

所属

Eureka

AP

Zookeeper

CP

Consul

CP

Eureka

Eureka 保证了可用性,实现最终一致性。

Eureka 所有节点都是平等的所有数据都是相同的,且 Eureka 可以相互交叉注册。

Eureka client 使用内置轮询负载均衡器去注册,有一个检测间隔时间,如果在一定时间内没有收到心跳,才会移除该节点注册信息;如果客户端发现当前 Eureka 不可用,会切换到其他的节点,如果所有的 Eureka 都跪了,Eureka client 会使用最后一次数据作为本地缓存;所以以上的每种设计都是他不具备[一致性]的特性。

注意:因为 EurekaAP 的特性和请求间隔同步机制,在服务更新时候一般会手动通过 Eureka 的 api 把当前服务状态设置为[offline],并等待 2 个同步间隔后重新启动,这样就能保证服务更新节点对整体系统的影响

Zookeeper

强一致性

Zookeeper 在选举 leader 时会停止服务,只有成功选举 leader 成功后才能提供服务,选举时间较长;内部使用 paxos 选举投票机制,只有获取半数以上的投票才能成为 leader,否则重新投票,所以部署的时候最好集群节点不小于 3 的奇数个(但是谁能保证跪掉后节点也是奇数个呢);Zookeeper 健康检查一般是使用 tcp 长链接,在内部网络抖动时或者对应节点阻塞时候都会变成不可用,这里还是比较危险的;

Consul

和 Zookeeper 一样数据 CP

Consul 注册时候只有过半的节点都写入成功才认为注册成功;leader 挂掉时,重新选举期间整个 Consul 不可用,保证了强一致性但牺牲了可用性

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值