CAP定理与Base理论

CAP定理：

一个分布式系统最多能同时满足一致性（Consistency）、可用性（Avaliablitity）和分区容错性（Partition tolerance）这三项中的两项。

  • 一致性（Consistency）:一致性指（all nodes see the same data at the same time）,即更新操作成功并返回客户端后，所有的节点在同一时间的数据完全一致。
  • 可用性（Avaliablitity）：可用性指（Reads and writes alaways succeed）,即服务一直可用，而且是正常响应时间。
  • 分区容错性(Partition tolerance)：分区容错性指（the system continues to operate despite arbitrary message loss or failure of part of the system）,即分布式系统在遇到某节点网络或者网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

    CAP的权衡：

    通过CAP定理的内容，可知分区容错性是一个分布式系统最重要的属性 即P这个点无论如何是不能丢弃的，所以分布式系统分为CP和AP
    CP（强一致性系统）常见于金融级系统 跟钱相关，必须要保证强一致性
    AP（高可用性系统）系统

    BASE理论：

    BASE理论是对于CAP理论的延申，核心思想就是即使无法做到强一致性（Strong Consistency CAP的一致性就是强一致性），但应用可以通过适合的方式达到最终一致性（Eventual Consistency）。
  • 基本可用（Basically Available）:基本可用性是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心功能可用。比如电商活动时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
  • 软状态(Soft State):软状态时指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个以上的副本，允许不同节点间副本同步的延时就是软状态的体现，Mysql Replication的异步复制也是一种体现
  • 最终一致性(Eventual Consistency):最终一致性指系统中所有的数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性时弱一致性的一种特殊情况。

    ACID和BASE理论的区别与联系

    ACID时传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，通过牺牲强一致性来达到数据的最终一致性。
    ACID和BASE代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合起来使用。
    当我们去访问一个大型的分布式系统时，CDN会根据我们的地址去连入到离我们最近的服务器，如此一来，当我们想不同的数据库中同一张表中插入数据的时候，如果使用主键自增，那么在两张表进行数据同步的时候会出现逐渐冲突，被称作（主主冲突），但是如果我们使用UUID当作主键的时候，因为主键是字符串，所以会大大降低我们检索数据的效率，因此分布式ID 应运而生，常见的是推特公司的雪花算法。
    image.png

    注册中心

    注册中心概述

    注册中心是微服务的灵魂所在，可以实现服务的注册与发现，实现服务的治理，市面上常见的注册中心软件：
    eureka(AP)
    Consul(CP)
    Nacos(AP)
    Zookeeper(CP)

    Zookeeper

    docker下安装Zookeeper

    1. //1.搜索 zookeeper镜像
    2. docker search zookeeper
    3. //2.拉取zookeeper镜像
    4. docker pull zookeeper
    5. //3. 查看本机所用可用的镜像
    6. docker ps -a
    7. //4.启动 zookeeper 容器
    8. docker run -d -p 2181:2181 --name zk --restart always zookeeper
    9. //5.查看启动的容器
    10. docker ps
    11. //6.进入容器
    12. docker exex -it //后面跟zookeeper的container id
    13. // 7.启动zookeeper客户端
    14. ./bin/zkCli.sh 
    15. //8.确认zookeeper是否启动 查询zookeeper的节点
    16. ls /

    将服务注册到zookeeper中

配置文件

  1. server:
  2. port: 8004
  3. spring:
  4.   application:
  5. name: cloud-provider-payment
  6.   cloud:
  7.     zookeeper:
  8.       connect-string: 175.24.232.70:2181 //zookeeper的ip端口

启动类

  1. @SpringBootApplication
  2. @EnableDiscoveryClient//将服务注册到zookeeper中
  3. public class PaymentMain8004 {
  4.     public static void main(String[] args) {
  5.         SpringApplication.run(PaymentMain8004.class,args);
  6.     }
  7. }

maven依赖

  1.        <!-- SpringBoot整合zookeeper客户端 防止依赖冲突，需要与服务器上的zookeeper版本保持一致 -->
  2.         <dependency>
  3.             <groupId>org.springframework.cloud</groupId>
  4.             <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId>
  5.             <!--先排除自带的zookeeper3.5.3-->
  6.             <exclusions>
  7.                 <exclusion>
  8.                     <groupId>org.apache.zookeeper</groupId>
  9.                     <artifactId>zookeeper</artifactId>
  10.                 </exclusion>
  11.             </exclusions>
  12.         </dependency>
  13.         <!--添加zookeeper3.7.0版本-->
  14.         <dependency>
  15.             <groupId>org.apache.zookeeper</groupId>
  16.             <artifactId>zookeeper</artifactId>
  17.             <version>3.7.0</version>
  18.         </dependency>

Zookeeper的节点

临时节点
create -e /k1 v1 zookeeper退出以后，节点直接消失
当服务停止以后 zookeeper的心跳同步机制收不到回复，就会干掉服务的节点 而eureka会有自我保护机制，当服务停止以后，会继续保存服务
持久节点

Consule

Consule的简介

Conule是一套开源的分布式服务发现和配置管理系统，由HashiCorp公司用Go语言开发。
提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格，总之Consule提供了一种完整的服务网格解决方案。

Consule主要功能：

1、服务注册与发现 （提供HTTP和DNS两种发现方式）
2、健康检查（支持多种方式、HTTP、TCP、Docker、Shell脚本定制化）
3、键值对存贮（Key、Value存储）
4、多数据中心 （Consule支持多数据中心）

三个服务中心的异同

image.png
CAP
C：Consistency 强一致性
A:Availability 可用性
P:Partition tolerance 分区容错性
CAP理论关注粒度是数据，而不是整体系统设计的 而分区容错性首先是要保证的 所以只能保证CP 或者AP