当前位置： 移动技术网 > IT编程>开发语言>JavaScript > 第三章 CAP定理

第三章 CAP定理

2020年07月17日  | 移动技术网IT编程  | 我要评论

什么是分布式CAP定理?

在这里插入图片描述
一言以蔽之:在分布式系统中,网络故障,服务瘫痪,整个系统然可工作.

分布式CAP举例思考

在这里插入图片描述
张三有100元优惠卷,在淘宝买了件衣服。
思考3个问题:
1.如何体现C数据一致性?
整个分布式系统中,一致性体现这笔订单,必须扣除100元优惠卷。
2.如何体现A可用性?
整个分布式系统中,可用性体现在张三下订单的时候,如果订单服务或卡卷服务瘫痪了,这时不能影响张三下订单。(一般做法是采用集群部署)
3.如何体现P分区容错性?
整个分布式系统中,分区容错体现在张三下订单的时候,突然订单服务和卡卷服务之间的网络断开了、但是不能影响张三下订单。

关键概念:什么是分区?

在这里插入图片描述
在断网的情况下,2台系统变成了独立网络,各自访问不了,这种情况就是分区。
在分区的情况下,如果要保持数据一致性和系统可靠性,那就是分区容错性了。

CAP技术实现,所面临的困惑

在分布式系统中,出现网络故障P,服务瘫痪A,整个系统的数据仍然保持一致性C。—根本无法做到
相对可以实现的方案:
业界的做法CAP,三选其二
CP
AP
CA ???
在这里插入图片描述
当服务之间出现网络故障的情况下:
1.如何保证订单服务和卡卷服务高可用?
2.下一笔订单同时扣除100元优惠卷如何实现?
分布式系统的解决方案:
1.CAP牺牲一致性(AP）:保证高可用（保证订单服务可以正常访问,保证卡卷服务可以正常访间,是牲了数据的一致性。
张三下单成功,但是不扣除100元优惠卷,这种情况下,张三下订单成功后再去查看100元,居然还存在。
怎么办?如何解决这种问题?
一般的做法是,当网络恢复正常的情况下,订单服务重试请求卡卷服务,再扣除100元优患卷。
2.CAP牺牲可靠性（CP）:保证数据一致性,即为了保证数据的强一致性,当张三来下订单的时候,提示:“系统维护中”。等服务间的网络恢复正常后,张三再来下订单。

思考:不要P,只留CA?

不要P分区,即不允许网络出现故障,这是不可能实现的。
所以在分布式系统中,是不存在CA。
即使单体系统也做不到CA,因为单体系统也会出现单一故障。

图解zOokeeper的CAP原理

在这里插入图片描述
zookeeper是CP的原理,即保证了数据一致性,牺牲了可用性。
zk的数据同步原理:例如:client1注册给了server1,server1同步给了server2,server2广播同步给各个
follower,为了保证数据的一致性,只有这整个过程都成功了,client1才收到注册成功。
在这里插入图片描述
当leader重启或网络故障的情况下,整个zk就会重新选举leader,在选举期间,client不能注册的,即zk不可用,所以牺牲了可用性。
在这里插入图片描述
只有等到整个系统选举成功后,系统才恢复注册,故zk为了保证数据一致性,牺牲了可靠性。
CP有一个致命的缺点,就是在大型分布式系统中,网络是非常复杂得,leader出现了故障的频率是非常高的,而且很容易引发雪崩。所以很多大型分布式系统都不选择zk的原因。

图解eureka的CAP原理

在这里插入图片描述
eureka是AP原理,即保证了可用性,却牺牲了一致性。
eureka的数据同步原理:例如cliet1注册给了server1,server1直接告诉client成功。
剩下的就是server1同步给server2,为了保证服务的可用性,他们都是异步同步的。

CAP定理常见面试题

面试题:
如果你的简历有写dubbo或springcloud,那面试官一般就会问你CAP定理了。
1.请说说什么是分布式CAP定理?
2.一般还会细问"什么是分区容错性?"因为这个是CAP的核心。
3.zookeeper和eureka的CAP区别?
思考题:
你们公司的分布式架构师怎么做的?哪些系统设计成了CP,AP?

本文地址：https://blog.csdn.net/yaoayao123/article/details/107388414

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网