JAVA分布式CAP原则

分布式CAP原则主要是使用SpringCloud框架的时候会涉及到该部分知识点

CAP原则指的是在一个分布式系统中,一致性,可用性,分区容错性

实际的项目开发中,这三者往往是不可兼顾的。

 

AP:牺牲一致性,保证可用性和分区容错性

CP:牺牲可用性,保证一致性和分区容错性

CA:放弃分区容错性,保证一致性和可用性

实现这些策略的方式有使用基于数据库的分布式方案属于AP型,使用缓存+数据库的方案,先更新数据库在进行缓存更新,可能出现短暂的不一致,但可以保证AP型 

对CAP的理解

假如有客户端在浏览器访问用户A,A部署了2台服务器,分别在2个同样的服务节点有S1,S2存放的数据都是V0,他们之间的网络是互通的,也就是相当于分布式系统的两个部分。

业务具体的操作流程:

1 客户端A更新了数据V1到S1

2 S1节点需要把这个消息告诉S2节点/想让S2更新数据/却发生网络故障,S2中保存的还是V0

3 客户端向S2请求数据,S2返回了V0数据

系统网络发送了故障,系统运行是正常的所以是具有容错性

客户端A访问节点S1的时候更新V0到V1,客户端A访问节点S2的时候是V1因此需要等待网络故障恢复,将S2节点同步更新

在网络恢复的这段时间,想要系统满足可用性是不可能的。因此可用性的要求随时随地访问系统都是正确有效的。这就出现了矛盾

项目中我们可以选择要么牺牲数据一致性,响应旧的数据V0给客户/或者牺牲可用性/组赛等待直到网络连接恢复。数据更新操作完成之后,再给用户响应最新的数据V1

所以说实际项目中,我们要有取舍策略

一般来说,分区容错无法避免,因此可以认为CAP的P是总会成立的,CAP定理告诉我们,剩下的C和A无法同时做到。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值