【SpringBoot】（CAP原则）以及（Eureka与Zookeeper的区别）【精讲】

最新推荐文章于 2024-10-01 15:25:04 发布

StudiousTiger

最新推荐文章于 2024-10-01 15:25:04 发布

阅读量612

点赞数

分类专栏： Tiger の SpringCloud 文章标签： zookeeper eureka 数据库 CAP原则 spring cloud

本文链接：https://blog.csdn.net/m0_45067620/article/details/119916136

版权

Tiger の SpringCloud 专栏收录该内容

11 篇文章 1 订阅

订阅专栏

文章目录

一、CAP原则

1、简介

在分布式系统中存在CAP原则，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

     ①、一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
     ②、可用性（Availability）：保证每个请求不管成功或者失败都有响应。
     ③、分区容忍性（Partition tolerance）：系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP 原则的精髓就是要么 AP，要么 CP，我们不考虑 CA（因为 P 是必须的）。在分布式系统中，如果只有一份数据，那么肯定可以保证数据的一致性，但是如果出现宕机则数据库系统不可用。即在此情况下获得了CP系统，但是CAP不可同时满足。
在这里插入图片描述

因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术（特点是复制的数据与源数据有时间差，但这种复制对生产系统性能影响较小）来实现集群化的数据一致性。

2、可用的抉择

CAP 理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性（C）和可用性（A）之间进行权衡，没有 NoSQL 系统能同时保证这三点。对于 web2.0 网站来说，关系数据库的很多主要特性却往往无用武之地。

数据库事务一致性需求：很多 web 实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求：对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。但是对于很多 web 应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3、与 SQL 的关系

传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL 系统通常注重性能和扩展性，而非事务机制。事务就是强一致性的体现，这也就意味着 NoSQL 更不倾向于 C（Consistency）。

传统的 SQ L数据库（关系型数据库）的事务通常都是支持 ACID 的强事务机制。
     ①、A（Atomicity）代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行。
     ②、C（Consistency）代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况。
     ③、I（Isolation）代表隔离性，即两个事务不会相互影响，覆盖彼此数据等。
     ④、D（Durability）表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。

NoSQL 系统仅提供对行级别的原子性保证，也就是说同时对同一个 Key 下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个 Key-Value 对不会被破坏。

4、与 BASE 的关系

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。

基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：
①、响应时间上的损失：正常情况下，一个在线搜索引擎需要 0.5 秒内返回给用户相应的查询结果，但由于出现异常（比如：宕机），查询结果的响应时间增加到了 1~2 秒。
②、功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。（降级）

弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

二、Eureka 与 Zookeeper 的区别

1、Eureka 保证的是 AP

在这里插入图片描述
在分布式环境中，可用性是保证每个请求不管成功或者失败都有响应。Eureka 保证的是AP，这也就意味着所有的节点是平等的，没有主从关系。

这样的好处是当一个节点出现故障，则会自动的切换到其他的节点，并不会因为其他节点宕机导致该节点不可用。但是这样也会到来一个问题，不能保证响应的数据时最新的。

除此之外，Eureka 存在一种自我保护机制，如果15分钟内，存在超过85%的节点没有正常的心跳，那么Eureka 将会认为客户端与注册中心（服务端）出现了网络故障，会出现以下几种情况：
①、Eureka 不会从注册表中移除没有"心跳"的服务。

②、Eureka 任然可以接收新的服务的注册以及新的请求的查询，但是不会同步到其他节点，保证当前节点任然可用。

③、当恢复心跳（网络稳定）时，将会重新同步其他节点。

2、Zookeeper 保证的是 CP

在这里插入图片描述
在分布式环境中，一致性是指数据在多个副本之间是能够保持数据一致的特性。zookeeper保证的是CP，也就意味着所有的节点的数据可以保持一致。例如一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，其他节点上的数据也应该得到更新，并且所有用户都可以读取到其最新的值。