SpringCloud入门(六) ------CAP理论以及Eureka与zookeeper的区别

最新推荐文章于 2024-08-07 02:33:40 发布

jym12138

最新推荐文章于 2024-08-07 02:33:40 发布

阅读量4.8k

点赞数 1

分类专栏： springcloud

本文链接：https://blog.csdn.net/weixin_43326401/article/details/104553449

版权

springcloud 专栏收录该内容

32 篇文章 4 订阅

订阅专栏

CAP理论

CAP理论概述

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
在这里插入图片描述

Consistency 一致性：

即所有节点在同一时间的数据完全一致。

一致性的类别:

强一致性
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
弱一致性
如果能容忍后续的部分或者全部访问不到，则是弱一致性。

最终一致性
如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

Availability 可用性

服务在正常响应时间内一直可用。

好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。

Partition Tolerance分区容错性

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

CAP的证明

在这里插入图片描述
网络中有两个节点N1和N2，可以简单的理解N1和N2分别是两台计算机，他们之间网络可以连通，N1中有一个应用程序A，和一个数据库V，N2也有一个应用程序B2和一个数据库V。现在，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库。

在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。
在这里插入图片描述
上图是分布式系统正常运转的流程，用户向N1机器请求数据更新，程序A更新数据库Vo为V1，分布式系统将数据进行同步操作M，将V1同步的N2中V0，使得N2中的数据V0也更新为V1，N2中的数据再响应N2的请求。

这里，可以定义N1和N2的数据库V之间的数据是否一样为一致性；外部对N1和N2的请求响应为可用性；N1和N2之间的网络环境为分区容错性。

这是正常运作的场景，也是理想的场景，然而现实是残酷的，当错误发生的时候，一致性和可用性还有分区容错性，是否能同时满足，还是说要进行取舍呢？

作为一个分布式系统，它和单机系统的最大区别，就在于网络，现在假设一种极端情况，N1和N2之间的网络断开了，我们要支持这种网络异常，相当于要满足分区容错性，能不能同时满足一致性和响应性呢？还是说要对他们进行取舍。

当N2数据进行一致性操作的时候，外界访问N2，就会等待，所以可用性就不会被满足
在这里插入图片描述
假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1，由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧是V0；这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？

有二种选择，第一，牺牲数据一致性，响应旧的数据V0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作M完成之后，再给用户响应最新的数据V1。

这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。

因此具体使用AP还是CP，只能根据场景定夺，适合的才是最好的。

Eureka与 Zookeeper的区别

Eureka：保证CAP 中满足 AP

在设计是就优先保证可用性，因此在设计时，Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余节点依然可以提供注册和查询服务，而Eureka的客户端在向某个Eureka 注册或发现连接失败，则会自动切换至其他节点,只要有一台Eureka在，就能保证注册服务的可用性，只不过查到的信息不是最新的（不保证强一致），除此之外，Eureka还有一种自我保护机制，如果15分钟内超过85%的节点都没有正常的心跳，那么Eureka 就认为客户端与注册中心出现了网络故障，此时会出现一下几种情况:
1.Eureka 不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka 仍能够接受新服务的注册和查询请求，但是不会同步到其他节点
3.网络稳定是，当前实例新的注册信息会同步到其他节点中
因此 Eureka 可以很好的应对网络故障导致部分节点失去联系的情况，而不是像zookeeper那样导致整个注册服务瘫痪

Zookeeper：保证CAP中满足 CP

向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟前的注册信息，但是不能接受服务直接down掉不可用，也就是说，服务注册功能对可用性要求要高于一致性，但是zk会出现一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。选举的时间过长，在此期间 zookeeper集群不可用，这就导致了选举期间，服务的注册瘫痪，因此漫长的选举时间导致的注册长期不可用是无法容忍的。