戴上 CAP 这顶帽子,又能和面试官扯皮了

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

转载声明:转载请注明出处,本技术博客是本人原创文章

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 戴上 CAP 这顶帽子,又能和面试官扯皮了

  点击上方 **好好学java **,选择 **星标 **公众号


重磅资讯、干货,第一时间送达
今日推荐:终于放弃了单调的swagger-ui了,选择了这款神器—knife4j个人原创+1博客:点击前往,查看更多

随着微服务和分布式系统的广泛运用,CAP 定理被大家熟悉起来,也成为了分布式系统的三大指标。这篇文章我们就来聊一聊 CAP 定理。

CAP 定理

CAP定理是加州大学的计算机科学家 Eric Brewer 在 1998年提出,Eric Brewer 说分布式系统有三个指标:

  • Consistency.- Availability.- Partition Tolerance.
    并且无法同时满足这三项指标,也就演变成了现在的 CAP 定理。

「Consistency(一致性)」:指读写数据的一致性,特指分布式系统中数据的一致性。如何理解这句话?

假设我们现在有G1、G2 两个实例,现在的值都是 v0,有一个客户端向 G1 发起更新请求,将 v0 更新为 v1,如下图所示:

在不做任何处理的情况下,G1实例对应的值为 v1,G2对应的值为v0。「如果此时客户端发起读请求,读 G1 实例上的数据是 v1,读 G2 实例上的值是 v0,这就出现了数据不一致,这就不满足数据一致性」。如何保证数据一致性?需要在 G1 写操作的时候,让 G1 向 G2 发送一条消息,要求 G2 也改成 v1。

附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南,这是本人这几年及春招的总结,目前,已经拿到了大厂offer,拿去不谢!

下载方式

1. 首先扫描下方二维码

2. 后台回复「Java面试」即可获取

这样的话,两个实例的值都是 v1,不管客户端读取哪个服务器获取的数据都一样,这就是数据一致性。「用大白话来讲就是多实例之间任何时刻数据都要相同。」

「Availability(可用性)」:指服务的高可用,特指分布式系统中服务的高可用,这个就比较好理解,就是我给你发一个请求,你必须给我一个正确的响应。「用大白话来讲就是每时每刻都需要给我响应。」

「Partition Tolerance(分区容错性)」:指在分布式系统遇到网络分区的情况下,仍然可以响应用户的请求。怎么理解呢?

在我们的分布式系统中,节点组成的网络本来应该是连通的。然而可能「因为某些故障,使得有些节点之间不连通了,整个网络就分成了几块区域,而数据就散布在了这些不连通的区域中,这就叫分区」。容错的意思就是分区了也需要能够正常访问,大白话就是不要出现单点故障。在分布式系统中,网络抖动、故障是不可避免的所以 「CAP 中,P 是必须实现的,只能在 CA 上做取舍」

接下来我们就来看看 CAP 的选择策略及在开源中间件的运用,加深对 CAP 的理解。

保 CP 弃 A

对数据一致要求比较的场景,可以牺牲一定的可用性,来保证数据的一致性,也就是强一致性。比如金融行业,因为它任何时候都不允许出现数据不一致的情况,否则就会给用户造成损失。因此,这种场景下必须保证 CP。

在我们的开源中间件中,「ZooKeeper 就是采用保 CP 弃 A 策略」,一起来看看。

在 ZooKeeper 集群中,Leader 节点之外的节点被称为 Follower 节点,「Leader 节点会专门负责处理用户的写请求」

  • 当用户向节点发送写请求时,如果请求的节点刚好是 Leader,那就直接处理该请求;- 如果请求的是 Follower 节点,那该节点会将请求转给 Leader,然后 Leader 会先向所有的 Follower 发出一个 Proposal,等超过一半的节点同意后,Leader 才会提交这次写操作,从而保证了数据的强一致性。
    具体示意图如下所示:

当出现网络分区时,「如果其中一个分区的节点数大于集群总节点数的一半,那么这个分区可以再选出一个 Leader,仍然对用户提供服务,但在选出 Leader 之前,不能正常为用户提供服务」

如果形成的分区中,「没有一个分区的节点数大于集群总节点数的一半,那么系统不能正常为用户提供服务,必须待网络恢复后,才能正常提供服务」

这种设计就是保证了数据的一致性,但是牺牲了一定的可用性,比如当 Leader 宕机的时候。

保 AP 弃 C

保 AP 弃 C 的策略是比较常见的策略,我们为了追求系统的高可用性,在出现网络抖动的情况下,允许数据暂时不一致,牺牲一定的数据一致性。

网络分区出现后,各个节点之间数据无法马上同步,为了保证高可用,分布式系统需要即刻响应用户的请求。但是此时可能某些节点还没有拿到最新数据,只能将本地旧的数据返回给用户,从而导致数据不一致的情况。

比如我们的 eureka 注册中心就是采用这种策略,在 eureka 集群中,当某个实例宕机了,并不会导致整个 eureka 注册中心不可用,活跃的 eureka 服务器仍然可以响应外部请求。当宕机的服务器重新启动后,在第一次数据同步之前,eureka 实例之间的数据是不一致的,但是经过一次数据同步之后,实例之间的数据就一致了,这就是通过牺牲数据的一致性,来保证系统的高可用。

最后,再附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南,这是本人这几年及春招的总结,目前,已经拿到了大厂offer,拿去不谢!

下载方式

1. 首先扫描下方二维码

2. 后台回复「Java面试」即可获取

原文地址:https://sihai.blog.csdn.net/article/details/109465599

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

转载声明:转载请注明出处,本技术博客是本人原创文章

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 戴上 CAP 这顶帽子,又能和面试官扯皮了


 上一篇
分享大厂分布式唯一ID设计方案,快来围观 分享大厂分布式唯一ID设计方案,快来围观
  点击上方 **好好学java **,选择 **星标 **公众号 重磅资讯、干货,第一时间送达 今日推荐:终于放弃了单调的swagger-ui了,选择了这款神器—knife4j个人原创+1博客:点击前往,查看更多 作者:老顾聊
2021-04-04
下一篇 
程序员入职国企,1周上班5小时,晒出薪资感叹——腾讯当CEO也不去 程序员入职国企,1周上班5小时,晒出薪资感叹——腾讯当CEO也不去
  点击上方 **好好学java **,选择 **星标 **公众号 重磅资讯、干货,第一时间送达 今日推荐:终于放弃了单调的swagger-ui了,选择了这款神器—knife4j个人原创+1博客:点击前往,查看更多 不同的企业工作环境都
2021-04-04