本篇文章给大家分享的是有关微服务架构中的CAP原理是什么,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
什么是分布式 CAP 原理,什么是分区容错性,zookeeper 和 eureka 的 CAP 区别是什么,还有作为公司的架构师你们是怎么做的,那些分布式系统设计成了 CP、AP,为什么这样设计等等一系列问题。
C(Consistency)
:一致性,即数据一致性,特指分布式系统中的数据一致性。
A(Availability)
:可用性,即服务的高可用,特指分布式系统中服务的高可用,某个服务瘫痪不影响整个分布式系统的正常运行。
P(Partition Tolerance)
:分区容错性(也有的叫分区耐受性),即网络故障,特指分布式系统中服务之间出现了网络故障,整个分布式系统仍然保持可用性和一致性。
一句话概括 CAP
:在分布式系统中,网络故障,服务瘫痪,整个系统的数据仍然保持一致性。
上面的表述可能不容易理解,举一个通俗的例子讲讲什么是分布式 CAP 原理。
如上图所示,小张在京东商城准备购买几本微服务实战相关的书籍,订单总金额共 200 元,他刚好有一张满 200 减 100 元的优惠劵。
这时分 3 种情况说明分布式系统的 CAP 如下:
数据一致性体现
:
使用 100 元优惠劵扣减,实付 100 元,优惠劵用完。
使用 100 元优惠劵失败,实付 200 元,优惠劵还在。
系统可用性体现
:
小张下订单时,订单服务或是 PLUS 会员服务挂了,此时不应该影响小张下单。
系统分区容错性体现
:
小张下订单时,订单服务和 PLUS 会员服务之间网络不通也不能影响小张下单。
CAP 定理中最难理解的概念是 P,分区容错性,画个图大家就理解了。
在断网的情况下,2 台服务器变成了独立网络,彼此无法通信,这个情况就是分区。在分区的情况下,分布式系统如果要保证数据一致性和可用性的话,那就满足分区容错性了。
目前大部分互联网企业都是微服务架构,即分布式系统。
现在某电商微服务架构,假设出现网络故障(P),服务挂掉(A),整个系统的数据仍然保持一致。这是无法做到的。
相对可以实现的方案:
业界的做法是 CAP 三选其二,即
CP
AP
CA
(请思考?后面叙述)
当服务之间出现网络故障的情况下:
问题:
如何保证订单服务和 PLUS 会员服务高可用?
下订单同时扣除 100 元优惠劵如何实现?
分布式系统的解决方案:
CAP 牺牲一致性(AP)
:保证高可用,即保证订单服务可以正常访问,保证 PLUS 会员服务可以正常访问,牺牲了数据的一致性。
小张去京东商城下订单(但是没有扣除 100 元优惠劵),这种情况下,小张订单提交成功后,再去查看 100 元优惠劵还在,居然没有扣除成功,但是实付金额是 100 元,很纳闷(心里窃喜)。
怎么办呢?如何解决这种问题?
一般的做法是,当网络恢复正常的情况下,订单服务重试请求 PLUS 会员服务,再扣除 100 元优惠劵。
CAP 牺牲可用性(CP)
:保证数据一致性。
当小张去京东商城下单时,提示:“网络异常,请稍后再试”。
怎么办呢?如何解决这种问题?
只能等网络恢复正常后,小张才可以成功下单。
CAP 牺牲分区容错性(CA)
:不要P分区,即不允许出现网络故障,这是不可能实现的。
所以在分布式系统中,是不存在 CA 的。即使传统单体系统也做不到CA,因为单体系统也会出现单一故障。
通过小张在京东商城下订单的案例,小伙伴应该都弄明白了吧。
1)图解 zookeeper 的 CAP 原理
注:此处不介绍 zookeeper 底层原理和实现
zookeeper 作为微服务注册中心是 CP 原理,即保证了数据的一致性,牺牲了可用性。如下图所示:
zookeeper 的数据同步原理:
Client1 客户端向 zk Server1 注册,zk Server1 同步信息给 zk Server2,zk Server2 是注册中心的 leader 节点,该节点负责把消息广播同步给其他 follower 的 zk 节点,为了保证数据的一致性,只有等整个注册中心信息同步完成,Client1客户端才能收到注册成功的消息。
如上图所示,当注册中心 leader 重启或是出现网络故障的情况下,整个 zk 集群重新选举 leader 节点,在选举期间,Client 客户端无法注册,即此时 zookeeper 服务不可用,所以牺牲了系统的可用性。
如上图所示,只有等到整个系统选举出 leader 节点,系统才能恢复注册,故 zookeeper 为了保证数据一致性,牺牲了系统的可用性。
CP 有一个致命的缺点,就是在大型分布式系统中,网络非常复杂,leader 节点出现故障的频率特别高,而且很容易引起雪崩。所以这是很多大型分布式系统都不选择 zookeeper 作为注册中心的原因。
2)图解 Eureka 的 CAP 原理
如下图所示:
eureka 是 AP 原理,即保证了系统的可用性,却牺牲了系统的一致性。
eureka 的数据同步原理:
第一步,Client1 客户端注册到 eureka Server1 服务中;
第二步,eureka Server1 直接告诉 Client1 注册成功。
第三步,eureka Server1 把 Client1 的注册信息同步给 Server2,为了保证服务的可用性,eureka Server 之间是异步同步的。
通过以上的案例描述和图形解读,相信大家对于微服务(分布式系统)架构中 CAP 原理有了一定的了解。比如知道了什么是 CAP 原理,什么是分区容错性,zookeeper 和 eureka 作为注册中心的 CAP 区别是什么。同时希望对今后你们公司的系统架构设计有所帮助,系统设计是遵循 CP 还是 AP。
以上就是微服务架构中的CAP原理是什么,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。