分布式
什么是分布式系统，分布式系统有什么好处？
分布式系统概念：分布式系统是由一组通过网络进行通信，为了完成共同的任务而协调工作的计算机节点组成的系统。具有高度的内聚性和透明性。
分布式系统的好处/优点：
可靠性高、容错性高
一台服务器的系统崩溃不会影响到其他服务器的运行。
扩展性好
分布式系统中可以根据需要增加服务器。
灵活性
容易添加新的服务。
高性能
性能比传统架构好，且性价比高
技术多样且开放。
顺便说一下缺点：
架构设计复杂。
管理和运维复杂。
部署复杂。
————————————————
版权声明：本文为CSDN博主「猿兄」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/love_MyLY/article/details/103409260
一、CAP原则
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VJCzQEcd-1677917448871)(SpringCloud分布式.assets/image-20230222140856742.png)]
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可 用性）、Partition tolerance（分区容错性），三者不可得兼。
CAP原则是NOSQL数据库的基石。
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
-
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访 问同一份最新的数据副本数据的一致性）
-
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据 更新具备高可用性）
-
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成 数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
一致性与可用性的决择编辑
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延 迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权 衡，没有NoSQL系统能同时保证这三点。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aqYcLopt-1677917448873)(SpringCloud分布式.assets/image-20230222141536378.png)]
什么是cap定理?
web服务无法同时满足cap定理
c 一致性性(Consistency):更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。
a 可用性(Availability):系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
p 分区容错性(Partition tolerance):即使出现单个组件无法可用，操作依然可以完成
.什么是分布式事务？
分布式事务保证分布式系统的数据一致性，分布式系统上一次大的操作由多个小的操作完成，每个小操作都在不同的应用执行，分布式事务就是要保证这些操作要么失败，要么成功。
BASE理论
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展。
- 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
- ==软状态:==允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
- 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。
BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
什么是base定理？
cap定理的a和p的延伸，通过牺牲一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
为什么分布式系统无法同时保证一致性和可用性？
对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。
4.实现分布式事务一致性（Consistency）的方法有哪些?
最著名的就是二阶段提交协议、三阶段提交协议和Paxos算法。
两阶段提交协议
- prepare(准备阶段)
当开始事务调用的时候，事务处理器向事务执行者（有可能是数据库本身支持）发出命令，事务执行者进行prepare操作。
当所有事务执行者都完成了prepare操作，就进行下一步行为。
如果有一个事务执行者在执行prepare的时候失败了，那么通知事务处理器，事务处理器再通知所有的事务执行者执行回滚操作。
- commit(提交阶段)
当所有事务执行者都prepare成功以后，事务处理器会再次发送commit请求给事务执行者，所有事务执行者进行commit处理。
当所有commit处理都成功了，那么事务执行结束。
如果有一个事务执行者的commit处理不成功，这个时候就要通知事务处理器，事务处理器通知所有的事务执行者执行回滚(abort)操作。
但是两阶段提交的诟病就是在于性能问题。比如由于执行链比较长，锁定资源的时间也变长了。所以在高性能的系统中都会避免使用二阶段提交。
springcloud
分布式锁的几种实现方式
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。 其典型的使用场景为： 不同系统或者是同一系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，需要通过 一定的互斥手段来防止彼此的干扰，以保证一致性。
使用Redis实现分布式锁
* WATCH, MULTI, EXEC, DISCARD事务机制实现分布式锁
Redis支持基本的事务操作
MULTI
some redis command
EXEC
以上被MULTI和EXEC包裹的redis命令==，保证所有事务内的命令将会串行顺序执行==，保证不会在事务的执 行过程中被其他客户端打断。 而WATCH命令能够监视某个键，当事务执行时，如果被监视的键被其他客户端修改了值，事务运行失 败，返回相应错误（被事务运行客户端在事务内修改了值，不会造成事务运行失败）。
通过WATCH命令监视某个键，当该键未被其他客户端修改值时，事务成功执行。当事务运行过程中，发 现该值被其他客户端更新了值，任务失败，进行重试。
* SETNX实现分布式锁
SETNX key value
将 key 的值设为 value，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
SETNX 是SET if Not eXists的简写。
返回值
返回整数，具体为
- 1，当 key 的值被设置
- 0，当 key 的值没被设置
服务注册和发现是什么意思？
Spring Cloud 如何实现？ 当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添 加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可 能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器 上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。
什么是Hystrix 断路器？我们需要它吗？
由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用 Hystrix 我们定义了一 个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。
什么是Spring Cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础 设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都 可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家 公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了 复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具 包。
SpringCloud与Dubbo的区别
两者都是现在主流的微服务框架，但却存在不少差异：
- 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理
- 生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
- 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，==接口一般是Java的Service接口，格式固定。==但调用时采用Netty的NIO方式，性能较好。
- 组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper
SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。
Spring Cloud Netflix Netflix OSS
开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。
Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
Feign：基于Ribbon和Hystrix的声明式服务调用组件；
Zuul：API网关组件，对请求提供路由及过滤功能。
Spring Cloud Sleuth
Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟 踪。
Spring Cloud OpenFeign
基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC 注解的接口实现用于服务 调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。
Spring Cloud断路器的作用
当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应 当更多 的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）断路器有完全打开状态(半打开状态):一段时 间内 达到一定的次数无法调用 并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求就不会请求 到该服务半开:短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭 关闭：当服务一直处于正常状态 能正常调用