首页 > 编程知识 正文

cap base理论及其应用,java cap理论

时间:2023-05-03 12:24:20 阅读:16345 作者:4053

在计算机领域,初学者就可以了,但是多年的老代码农不懂CAP定理的话,真的很难说。 CAP是所有技术修订者必须掌握的基础原则啊。

当前,稍大的互联网项目可能采用分布式结构,在一个系统中配置多个节点,每个节点都需要维护一个数据。 下面,如何维持各节点之间的状态,如何保障各节点之间的数据同步备受关注。

CAP定理是分布式系统中最基础的原则。 因此,理解和掌握CAP对系统体系结构的设计至关重要。

一、什么是CAP?

也被称为布鲁姆定理的“CAP定理”提出,对于分布式系统来说,不能同时满足以下三点。

Consisteny(一致性)

Availability(可用性)

Partition tolerance(分区容错性)

也就是说,CAP定理表明,任何分散系统都只能同时满足这三个中的两个。

如上图所示,如果最多同时满足两个项目,则有CA、CP、AP三种组合。 在谈及这三者的组合之前,让我们分别看看“一致性”、“可用性”和“分区公差”的含义。

假设一个系统当前有两个节点a和b,两个节点可以分别在Actor中读写,并且两个节点之间的数据会自动同步。

Consisteny(一致性)

一致性要求是指任何客户端(上图中的Actor )在每次读取操作时都会获得最新的数据。 也就是说,一个客户机向a节点写入新数据后,其他客户机从b节点进行读取操作而得到的数据也是最新的,需要与a节点的数据一致。

Availability(可用性)

可用性要求是指每个请求都能在适当的时间内得到预期的响应。 不能保证获取的结果是最新的数据。

在上图中,客户端向a节点或b节点发出请求后,只要两个节点都收到请求,客户端就必须响应,但不需要保证响应的值是否正确。

Partition tolerance(分区容错性)

分区容错是指即使节点之间的网络出现问题,系统也可以正常提供服务。

在阐述了c、a、p的含义和要求后,让我们继续看看它们之间如何组合使用。

二、CAP如何应用?

让我们先把视野回到这张图:

我知道有CA、CP、AP三种组合方式,但分布式系统的结构不能使网络100%可靠。 既然网络不能保证绝对的可靠性,分区容错(p )是必需的选项。 理由如下。

如果选择了CA组合,则放弃分区容错(p )。 还是以上图中的a和b节点为例,节点间发生网络故障时,为了保证c (一致性),必须锁定系统,不允许任何写入操作,否则节点之间会发生数据不一致但是,锁定了系统,意味着在输入写入请求时系统不可用,这又违反了a (可用性)原则。

因此,分布式系统理论上不能组合CA,所以只能选择CP和AP的组合体系结构。

现在,让我们详细了解一下CP体系结构和AP体系结构的特点。

CP 架构

CP体系结构是一致性和分区容差的组合。

如上图所示,由于网络问题,节点a和b无法相互通信。 如果客户端(上图中的Actor )向节点a发出写入请求(准备写入消息2 ),则节点a不接收写入操作,写入失败。 这保证了节点a和节点b的数据完整性,也就是说,保证了一致性。

然后,当另一个客户端(上图中的另一个Actor )向b节点发出读取请求时,b请求返回网络故障前存储的信息(Message 1),该信息与节点a匹配,是整个系统最后成功写入的信息也就是说,分区容错) )保证了分区容错

这意味着CP体系结构有保障,但放弃了可用性建议。

AP 架构

AP体系结构是Availability和分区隔离的组合体系结构。

如上图所示,由于网络问题,节点a和b无法相互通信。 如果客户端(上图中的Actor )向节点a发出写入请求(准备写入消息2 ),则节点a允许写入,并且请求操作成功。 但是,此时,由于无法通信到a和b节点,所以b节点的数据保持旧的消息1。 客户端向b节点发出读取请求时,读取的数据为旧数据,与在a节点读取的数据不一致。 但是,系统可以照常提供服务,因此满足了可用性要求

因此,这种情况下,就是保障了AP架构,但其放弃了 Consisteny(一致性)。

三、CAP 注意事项?

了解了CAP定理后,对于开发者而言,当我们构建服务的时候,就需要根据业务特性作出权衡考虑,哪些点是当前系统可以取舍的,哪些是应该重点保障的。

即使是在同一个系统中,不同模块的数据可能应用的CAP架构都是不同的。举个例子,在某个电商系统中,属于用户模块的数据(账密、钱包余额等)对一致性的要求很高,就可以采用CP架构。而对于一些商品信息方面的数据对一致性要求没那么高,但为了照顾用户体验,所以对可用性要求更高一些,那么这个模块的数据就可以采用AP架构。

另外,虽然上面第二节讲到过我们只能选择CP和AP,无法选择CA。但这句话成立的前提条件是在系统发生了网络故障的情况下。然而,网络故障的概率在系统的整个生命周期中占比是很小的,因此我们在设计的时候,虽然要考虑网络问题下的方案,但也要考虑网络正常情况下的方案,即在网络正常情况下,CA是可以实现的,我们也需要去保证在绝大多数时间下的CA架构。

再者,即使我们按照CAP定理,三个中只能取其二,但不代表我们只需要保障其中的两点,而完全的放弃第三点,我们应该为不能保障的第三点也做一些防备措施或者冗余方案,来使系统更加的完善健全。

以上,就是对CAP定理的一些思考。

本文原创发布于微信公众号「 不止思考 」,欢迎关注,一起提升 认知、工作成长、大数据、架构、Web等技术。

码字不易啊,喜欢的话各位看官不妨转发朋友吧。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。