分布式系统CAP定理中的P原理解析

2024-09-29 14:16:08

引言

之前在看 CAP 定理时抱有很大的疑惑，CAP 定理的定义是指在分布式系统中三者只能满足其二，也就是存在分布式 CA 系统的。

在网络上查阅了很多关于 CAP 文章，虽然这些文章对于 P 的解释五花八门，但总结下来这些观点大多都是指 P 是不可缺少的，也就是说在分布式系统只能是 AP 或者 CP，这种理论与我之前所认识的理论（存在分布式 CA 系统）是冲突的，所以才有了疑惑。

这个定理起源于加州大学柏克莱分校（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在 2000 年的分布式计算原理研讨会（PODC）上提出的一个猜想。在 2002 年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。

什么是 CAP 定理（CAP theorem）

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

一致性（Consistency）（等同于所有节点访问同一份最新的数据副本）
可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。）

分区容错性（Partition tolerance）

理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点可以互相通信，才能既保证 C 又保证 A，这又会导致丧失 P 性质。

P 指的是分区容错性，分区现象产生后需要容错，容错是指在 A 与 C 之间选择。如果分布式系统没有分区现象（没有出现不一致不可用情况）本身就没有分区，既然没有分区则就更没有分区容错性 P。
无论我设计的系统是 AP 还是 CP 系统如果没有出现不一致不可用。则该系统就处于 CA 状态
P 的体现前提是得有分区情况存在

文章来源：维基百科 CAP 定理

几个常用的 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 不可用,保证了强一致性但牺牲了可用性有很多 blog 说 Consul 属于 ap，官方已经确认他为 CP 机制。

以上就是分布式系统CAP定理中的P原理解析的详细内容，更多关于分布式系统CAP的资料请关注我们其它相关文章！

分布式事务CAP两阶段提交及三阶段提交详解

目录 1 关于分布式系统 1.1 介绍 1.2 优势和不足 2 分布式事务 2.1 CAP理论 2.2 CAP的组合情况 2.3 数据一致性模型 2.4 分布式事务应用场景 2.4.1 典型支付场景 2.4.2 在线下单 2.4.3 跨行转账 2.5 常见分布式一致性保障(分布式事务解决方案) 2.5.1 XA 两阶段提交协议 2.5.2 XA三阶段提交 2.5.3 MQ事务 2.5.4 TCC事务 2.5.5 最终补偿机制,同于MQ事务 1 关于分布式系统 1.1 介绍我们常见的单体结构的集
分布式系统下调用链追踪技术面试题

引言一个复杂的分布式系统,用户发起一个请求,这个请求可能调用几十到几百个服务,经过很多业务层,而每个业务又是多个机器集群,一个请求具体被随机到哪台机器上又无法确定,如果最后用户的请求失败,只返回一个错误提示,作为开发人员,该如何定位解决问题?你需要定位以下问题: 问题出在哪个服务,是你负责的服务还是调用别人服务的某一个环节. 同一个服务集群有多台机器,到底要去哪个机房哪台机器定位某条报错信息. 同一个接口可能有多次请求,到底是哪一次报错了. 多个服务之间调用顺序是怎样的. 如果需要响应速度优化
java分布式面试CAP分别代表含义分析

目录引言 1.面试官,说到CAP定理,那能详细说说CAP分别代表什么吗? 2.面试官:听起来很简单,这只是概念,但是具体是什么意思呢? 举例深入分析总结引言上一节讲面试中被问到分布式系统概念相关的,讲完了分布式系统的概念,优点缺点和 RPC 后,我以为这个问题就到此结束了,没想到成功给自己挖了个坑(微笑脸),关于 CAP,以前只是听说过,并没有详细点整理过,这一次问好好整理了下. CAP 问题已经成了计算机科学中一个研究领域,之前说到分布式系统有哪些优势时讲到三个提升: 1. 系统可用性
分布式系统中的降级熔断设计问题面试

目录引言 1.面试官: 你对你负责的系统做了哪些提高可用性的设计? 总结引言稳定性设计第一篇:在分布式系统下,线上的某一个功能按钮背后会有很多个服务共同完成,这些服务之间有依赖关系,且有一定的顺序调用.那么这些服务如果其中有一个环节出现问题,会带来一些连锁反应. 比如,突如其来的流量,部分服务突然宕机,你能想到的故障都算故障,是不是整个服务都不可用了吗?作为开发者肯定不希望这样的事情发生,那么有哪些解决问题?思路就是尽量给每个服务找一个“备胎” ,这个“备胎”不是集群概念里一个备用机器 ,
交互分布式系统下如何生成唯一序列

目录 1 介绍 2 数据库自增 3 系统时间毫秒数 4 UUID(GUID) 5 批量预生成ID 6 Redis生成唯一序列 7 snowflake算法 8 UidGenerator 9 Leaf 10 总结 1 介绍在常见的业务场景中,比如全局订单Id,唯一标识的支付编号等,都需要这个来保证. 那生成ID都有哪些解决方案呢?特别是在复杂的分布式系统业务场景中,我们应该采用哪种解决方案来实现这个唯一序列呢? 一般来说,这个唯一序号有如下几种特征: 全局唯一性:确保生成的序列是全局唯一的,不可重
分布式系统CAP定理中的P原理解析

目录引言什么是 CAP 定理(CAP theorem) 分区容错性(Partition tolerance) 几个常用的 CAP 框架对比 Eureka Zookeeper Consul 引言之前在看 CAP 定理时抱有很大的疑惑,CAP 定理的定义是指在分布式系统中三者只能满足其二,也就是存在分布式 CA 系统的. 在网络上查阅了很多关于 CAP 文章,虽然这些文章对于 P 的解释五花八门,但总结下来这些观点大多都是指 P 是不可缺少的,也就是说在分布式系统只能是 AP 或者 CP,这种
Android中微信抢红包插件原理解析及开发思路

一.前言自从去年中微信添加抢红包的功能,微信的电商之旅算是正式开始正式火爆起来.但是作为Android开发者来说,我们在抢红包的同时意识到了很多问题,就是手动去抢红包的速度慢了,当然这些有很多原因导致了.或许是网络的原因,而且这个也是最大的原因.但是其他的不可忽略的因素也是要考虑到进去的,比如在手机充电锁屏的时候,我们并不知道有人已经开始发红包了,那么这时候也是让我们丧失了一大批红包的原因.那么关于网络的问题,我们开发者可能用相关技术无法解决(当然在Google和Facebook看来的话,他们
python实现布隆过滤器及原理解析

在学习redis过程中提到一个缓存击穿的问题, 书中参考的解决方案之一是使用布隆过滤器, 那么就有必要来了解一下什么是布隆过滤器.在参考了许多博客之后, 写个总结记录一下. 一.布隆过滤器简介什么是布隆过滤器? 本质上布隆过滤器( BloomFilter )是一种数据结构,比较巧妙的概率型数据结构(probabilistic data structure),特点是高效地插入和查询,可以用来告诉你 "某样东西一定不存在或者可能存在". 相比于传统的 Set.Map 等数据结构,它更高效
Java多态中动态绑定原理解析

这篇文章主要介绍了Java多态中动态绑定原理解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下多态是面向对象程序设计非常重要的特性,它让程序拥有更好的可读性和可扩展性. 发生在继承关系中. 需要子类重写父类的方法. 父类类型的引用指向子类类型的对象. 自始至终,多态都是对于方法而言,对于类中的成员变量,没有多态的说法. 一个基类的引用变量接收不同子类的对象将会调用子类对应的方法,这其实就是动态绑定的过程.在理解动态绑定之前,先补充一些概念.
一文助你搞懂参数传递原理解析(java、go、python、c++)

前言最近一年多的时间陆续接触了一些对我来说陌生的语言,主要就是 Python 和 Go,期间为了快速实现需求只是依葫芦画瓢的撸代码:并没有深究一些细节与原理. 就拿参数传递一事来说各个语言的实现细节各不相同,但又有类似之处:在许多新手入门时容易搞不清楚,导致犯一些低级错误. Java 基本类型传递先拿我最熟悉的 Java 来说,我相信应该没人会写这样的代码: @Test public void testBasic() { int a = 10; modifyBasic(a); System.
go语言实现简易比特币系统钱包的原理解析

钱包基础概念广义上,钱包是一个应用程序,为用户提供交互界面.钱包控制用户访问权限.管理比特比地址及秘钥.跟踪余额.创建交易和签名交易狭义上,即从程序员角度来看,"钱包"是指用于存储和管理用户秘钥的数据结构钱包是私钥的容器,一般是通过结构化文件或简单数据库来实现的钱包中并不包含比特币.比特币是被记录在比特币网络的区块链中,用户通过钱包中的密钥签名交易,从而控制网络中的比特币,在某种意义上,比特币钱包就是密钥链钱包结构体 type Wallet struct { //私钥 Pri
Java7和Java8中的ConcurrentHashMap原理解析

Java7 中 ConcurrentHashMap ConcurrentHashMap 和 HashMap 思路是差不多的,但是因为它支持并发操作,所以要复杂一些. 整个 ConcurrentHashMap 由一个个 Segment 组成,Segment 代表"部分"或"一段"的意思,所以很多地方都会将其描述为分段锁.注意,行文中,我很多地方用了"槽"来代表一个 segment. 简单理解就是,ConcurrentHashMap 是一个 Segm
java同步器AQS架构AbstractQueuedSynchronizer原理解析下

目录引导语 1.释放锁 1.1.释放排它锁release 1.2.释放共享锁releaseShared 2.条件队列的重要方法 2.1.入队列等待await 2.1.1.addConditionWaiter 2.1.2.unlinkCancelledWaiters 2.2.单个唤醒signal 2.3.全部唤醒signalAll 3.总结引导语 AQS 的内容太多,所以我们分成了两个章节,没有看过 AQS 上半章节的同学可以回首看一下哈,上半章节里面说了很多锁的基本概念,基本属性,如何获得锁
Apache Kafka 分区重分配的实现原理解析

目录一.前言二.工具的使用三.元数据管理及协调器 3.1 ZooKeeper 3.2 Kafka Controller 四.分区重分配流程分析 4.1 kafka-reassign-partitions 客户端 4.2 controller 维护分区的元数据信息 4.3 broker 端数据跨路径迁移五.总结本文作者为中国移动云能力中心大数据团队软件开发工程师孙大鹏,本文结合 2.0.0 版本的 Kafka 源码,详细介绍了 Kafka 分区副本重分配的流程和逻辑,供大家参考. 一.前
Golang errgroup 设计及实现原理解析

目录开篇 errgroup 源码拆解 Group WithContext Wait Go SetLimit TryGo 使用方法结束语开篇继上次学习了信号量 semaphore 扩展库的设计思路和实现之后,今天我们继续来看 golang.org/x/sync 包下的另一个经常被 Golang 开发者使用的大杀器:errgroup. 业务研发中我们经常会遇到需要调用多个下游的场景,比如加载一个商品的详情页,你可能需要访问商品服务,库存服务,券服务,用户服务等,才能从各个数据源获取到所需要的