CAP定理整理_craig定理

2022-11-17 13:04:12 浏览数 (2)

大家好,又见面了,我是你们的朋友全栈君。

CAP定理是分布式系统设计中最基础、最关键的理论,CAP定理又称CAP原则,指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),最多只能同时三个特性中的两个,三者不可兼得

CAP的定义

Consistency (一致性):

“all nodes see the same data at the same time”,即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致,这就是分布式的一致性。一致性的问题在并发系统中不可避免,对于客户端来说,一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。即每次读取要么获得最近写入的数据,要么获得一个错误。

Availability (可用性):

可用性指“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。也就是每次请求都能获得一个响应,这个响应是非错误的,但是不确保返回的是最新写入的数据。

Partition Tolerance (分区容错性):

即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。

分区容错性要求能够使应用虽然是一个分布式系统,而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统需求,对于用户而言并没有什么体验上的影响。

取舍策略

CAP三个特性只能满足其中两个,那么取舍的策略就共有三种:

CA without P:如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点,这是违背分布式系统设计的初衷的。比如两阶段提交(2PC)

CP without A:如果不要求A(可用),相当于每个请求都需要在服务器之间保持强一致,而P(分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务),一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。注意,CP关注的是系统中大多数人的一致性协议,比如Paxos 算法 (Quorum 类的算法)。设计成CP的系统其实不少,最典型的就是分布式数据库,如Redis、HBase等。对于这些分布式数据库来说,数据的一致性是最基本的要求,因为如果连这个标准都达不到,那么直接采用关系型数据库就好,没必要再浪费资源来部署分布式数据库。eg. Zookeeper

AP without C:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景,可能前几秒你浏览商品的时候页面提示是有库存的,当你选择完商品准备下单的时候,系统提示你下单失败,商品已售完。这其实就是先在 A(可用性)方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,虽然多少会影响一些用户体验,但也不至于造成用户购物流程的严重阻塞。eg. Eureka

作为服务发现产品,可用性优先级较高,一致性的特点则不重要,哪怕返回错误的数据,也比不返回结果要好一些。

服务列表变更Zookeeper服务端会有通知,Eureka则通过长轮询来实现,将来会实现watch机制。

我司使用了Zookeeper作为服务注册发现中间件,但是如上文所述,Zookeeper是CP系统,无法保证分布式下的可用性,需要使用AP系统。因此,公司大佬们实现AP系统服务注册发现,保证了数据的最终一致性。根据 Netflix Eureka 研发并优化的golang版本服务注册发现系统Discovery,与caster平台进行结合,基于k8s pod(k8s项目中的原子调度单位)实现滚动发布、蓝绿发布等,客户端使用HTTP协议与注册中心交互。 网络闪断时服务可开启自我保护,保证健康的服务可用。由于公司各部门开发语言不一致,有golang、java、python、php、C 等,再实现各个语言的sdk,基于http协议保证交互简易。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/226838.html原文链接:https://javaforall.cn

0 人点赞