分布式

谈谈你对分布式系统的理解

为了解决传统单体服务架构带来的各种问题，代码数量庞大，迭代测试维护困难，可能因为一处改动测试不到位造成整个服务瘫痪等问题。

分布式系统就是将一个大的服务拆分成几十个甚至上百个微小的服务。，代码不在一个项目里，方便大家分工开发，也不会冲突，便于项目维护

比如阿里的 Dubbo，还有 Spring 全家桶里的 Spring Cloud，都是解决分布式微服务架构的优秀框架。

分布式系统环境下各自有什么优缺点

优点：

• 系统可用性提升：分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。

• 系统并发能力提升：请求通过 Nginx 负载均衡被分发到不同的服务器上，运行同样代码的服务器可以有 1 台或 N 台，通常情况下会根据实际用户访问量随时增加机器

• 系统容错能力提升：同一组服务分别部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被自动分发到北京和上海的机房，不影响用户使用。

• 低延迟 ：北京的用户请求自动分发到北京，上海的用户请求被分发到上海，服务器会根据用户的 IP 选择距离自己最近的机房，降低网络延迟。

缺点：

分布式服务依赖网络：服务器间通讯依赖网络，不可靠网络包括网络延时，丢包、中断、异步，一个完整的服务请求依赖一连串服务调用，任意一个服务节点网络出现问题，都可能造成本次请求失败。

维护成本高：分布式服务系统被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，增加运维成本。

一致性，可用性，分区容错性无法同时满足：这三种特性最多只能满足两种，无法同时满足，需要根据实际情况去调整牺牲掉其中哪个。

CAP 理论是什么

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

• 一致性 : 所有节点访问同一份最新的数据副本
• 可用性: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性 : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

网络分区：分布式系统中，多个节点之间的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域。

CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

为什么不可能选择 CA 架构呢

举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了

如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。

如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

BASE 理论是什么

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

BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

基本可用：基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

• 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

软状态：允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

• 分布式一致性的 3 种级别：

1. 强一致性：系统写入了什么，读出来的就是什么。
2. 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
3. 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

分布式存储和一般存储的区别

1. 数据复制和冗余：分布式存储系统将数据分布在多个节点上，通过数据的冗余复制来提高数据的可靠性和容错能力。而一般存储系统通常是单节点或少数几个节点存储数据，没有数据的冗余备份。
2. 数据访问和负载均衡：分布式存储系统可以使用各种负载均衡算法，将数据请求分配到不同的节点，从而实现高并发的数据访问。而一般存储系统通常只能由单个节点处理所有的数据请求。
3. 扩展性和容量：分布式存储系统可以根据需求动态扩展节点，从而扩展存储容量和吞吐量。而一般存储系统的容量和性能通常受限于单个节点的硬件资源。
4. 数据一致性：分布式存储系统需要解决数据一致性的问题，即如何保证在分布式环境下多个副本之间的数据一致。而一般存储系统通常采用隔离级别、锁定机制等方法来保证数据的一致性。
5. 故障恢复：分布式存储系统可以通过故障转移和数据复制来实现故障恢复和容错。一般存储系统通常需要手动或半自动的方式来处理故障和数据恢复。

RPC是什么

RPC（Remote Procedure Call，远程过程调用）是一种计算机通信协议和编程模型，用于实现不同计算机或进程之间的远程通信。它允许一个计算机程序请求另一个计算机或进程上的服务，并获取返回结果，就像本地调用一样。

在 RPC 模型中，存在两个主要的角色：

1. 客户端（Client）：客户端发起 RPC 请求，就像调用本地函数一样。它将请求发送到远程主机上的服务提供者。
2. 服务提供者（Server）：服务提供者接收客户端的请求，并执行相应的操作或函数。然后，它将结果返回给客户端。

RPC 的好处包括：

• 简化了分布式系统间的远程通信，使得开发人员能够更自然地处理远程服务调用。
• 隐藏了底层通信细节，提供了类似本地函数调用的编程接口。
• 提高了代码的可维护性和可重用性，因为可以将远程调用封装为可复用的模块。

常见的 RPC 框架包括 gRPC、Apache Thrift、JSON-RPC 等。

RPC工作流程

1. 定义服务接口：首先，需要定义服务接口，即客户端可以调用的远程函数或方法。这包括要执行的操作、参数和返回值等。
2. 客户端调用：客户端通过本地调用方式调用远程服务。它使用与本地调用相同的语法和格式。客户端传递参数给远程服务，然后等待结果的返回。
3. 参数编码：客户端的 RPC 运行时库将调用信息打包为网络传输格式，例如序列化为二进制或使用类似 JSON 的数据格式。打包后的数据包含了远程方法名和参数。
4. 网络传输：打包后的请求通过网络发送到远程主机上的服务提供者。这通常是通过网络协议（如 TCP/IP）进行传输。
5. 服务提供者接收：服务提供者的 RPC 运行时库接收到请求后，负责解析请求并提取方法名和参数。
6. 方法调用：服务提供者调用对应的远程方法或函数，并将客户端传递的参数传入。实际的操作或计算在远程主机上执行。
7. 结果处理：当远程方法执行完成后，服务提供者将结果返回给客户端。结果可以是任何数据类型，例如返回值、错误码或其他自定义的数据结构。
8. 结果编码：服务提供者的 RPC 运行时库将结果打包为网络传输格式，和请求一样，可以是二进制或类似 JSON 的数据格式。
9. 网络传输：打包后的结果通过网络发送回客户端。
10. 客户端接收：客户端的 RPC 运行时库接收到结果后，负责解析结果并提取返回值或错误信息等。
11. 结果处理：最后，客户端的调用方可以获得远程方法的返回值或错误信息，并继续执行相应的操作。

整个过程中的参数编码、网络传输、结果编码等细节由 RPC 框架自动处理，开发人员只需要关注定义服务接口和进行方法调用。

spring cloud是什么

Spring Cloud 是一个开源的、基于 Spring Framework 的分布式系统开发工具包，它提供了一系列的工具和组件，用于构建分布式系统中常见的分布式配置管理、服务注册与发现、负载均衡、断路器、消息总线、分布式追踪等功能。

Spring Cloud 的目标是简化分布式系统的开发，通过提供标准化的解决方案，使得开发者可以更加轻松地构建和管理分布式应用。它基于 Spring Boot，利用 Spring 的依赖注入特性和其他核心功能，为分布式系统开发提供了一致性、可伸缩性和易操作性。

Spring Cloud 提供了以下主要功能：

1. 服务注册与发现：通过集成服务注册中心（如 Netflix Eureka、Consul）实现服务的自动注册与发现，使得服务可以在分布式环境中动态地扩展和调用。
2. 负载均衡：通过集成负载均衡器（如 Netflix Ribbon）实现服务的负载均衡，将请求分配到多个实例上，提高系统的容错能力和性能。
3. 断路器：通过集成断路器模式（如 Netflix Hystrix）实现服务的容错和故障处理，当依赖的服务出现故障或超时时，可以进行降级、熔断和快速失败等操作。
4. 配置管理：通过集成分布式配置管理工具（如 Spring Cloud Config、Consul）实现对应用配置的集中化管理和动态刷新，减少了重启应用的需要。
5. 消息总线：通过集成消息总线（如 Spring Cloud Bus）实现应用之间的消息广播和通信，方便实现配置的动态刷新和事件的传播。
6. 分布式追踪：通过集成分布式追踪系统（如 Zipkin、Sleuth）实现对请求的跟踪和监控，帮助识别和解决分布式系统中的性能问题。