分布式基础

摘要：汇总整理部分概念和理论...

1. 什么是分布式

        利用物理结构形成多个自治的处理元素，不共享主内存，但是通过发送信息合作。 — Leslie Lamport

2. 分布式的作用

        单体应用的问题

        速度变慢、熟悉项目工作量太大、耦合严重、合并代码冲突多，依赖冲突多

        分布式的好处

        开发、部署速度更快、技术升级空间大、可用性增强、成本低、资源利用率高、单体与分布式对比

	传统单体架构	分布式架构
项目启动速度	慢	块
团队规模	相对较小	相对较大
功能维护成本	较高，容易有冲突	较低
代码清晰度	较差，耦合严重	较好
可用性	一损俱损，殃及池鱼	故障影响范围较小
架构设计难度	较低	较高

3. CAP定理和Base理论

        我们知道数据库事务的基本特性ACID（即原子性、一致性、隔离性和持久性），用于确保事务的正确执行和数据的完整性。本节来学习下分布式基础理论

3.1 CAP定理

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

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

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

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。**也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

        因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。

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

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

CAP & BASE理论详解 | JavaGuide「Java学习 + 面试指南」一份涵盖大部分 Java 程序员所需要掌握的核心知识。准备 Java 面试，首选 JavaGuide！https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html

3.2 BASE理论

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

        Base理论的核心：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性，即为保证系统的高可用性牺牲数据的一致性。

        BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

        BASE理论三要素

        基本可用（Basically Available）：分布式系统在出现不可预知故障的时候，允许损失部分可用性（例如响应时间、系统功能的损失），但是这绝不等价于系统不可用

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

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

注：实现最终一致性的方式，读时修复（推荐）、写时修复、异步修复

        总结：ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

4. 集群、分布式、微服务的区别

        集群与分布式的区别

        分布式：不同的项目，部署在多个服务器上；集群：同一个项目，部署在多个服务器上。具体的说

• 分布式是不同的服务器节点完成不同的任务，集群是不同的服务器对外提供一致的服务
• 分布式就是将一个任务分摊到不同的节点共同完成，这几个节点是协同工作的，存在互相依赖的关系，其中一个挂掉了有可能使得其他节点都不能工作；而集群就是多个节点执行相同的任务，互不干扰，就像饭堂的窗口，每个窗口的职能都是一样的，在哪个窗口都能达到目的，随便关了哪个窗口都可以，只要还有窗口可用，客人就能排队打饭
• 集群要解决的是可靠性，而分布式的主要工作是分解任务，将职能拆解。
• 分布式：不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题 ；集群：同一个业务部署在多台机器上，提高系统可用性

        集群与微服务的区别

        集群：分散压力；微服务：分散能力

• 范围不同：集群是一组计算机节点的集合，用于提供资源共享和协同工作；而微服务是一种软件架构风格，强调将单一应用程序拆分为多个小型、独立部署的服务。
• 关注点不同：集群关注于基础设施层面，用于提供资源和服务的高可用性和扩展性；微服务关注于应用程序的设计和架构，以实现灵活性、可维护性和可扩展性。
• 设计理念不同：集群设计是为了提高系统的整体性能和可靠性；微服务设计是为了提高应用程序的灵活性、可维护性和可扩展性，通过解耦和独立部署来实现这些目标。

        微服务和分布式的区别

        微服务是架构设计方式，按照业务垂直拆分；分布式是系统部署方式，拆分后分开部署，就是分布式

• 目标不同：微服务架构旨在将单个复杂应用程序分解为一系列小型服务，每个服务都专注于特定的业务功能，并独立部署和管理，这些服务通常使用轻量级机制（如HTTP API）进行通信；分布式系统是将计算任务分散到多个计算机或网络上，以提高系统的可扩展性、可靠性，并减少单一节点故障的风险
• 组成不同：微服务的粒度更细，通常关注单一业务功能或业务流程，并且这些服务可以部署在单个或多个服务器上，而分布式系统的粒度相对较粗，每个子系统可能包含多个功能，负责不同的任务
• 部署方式不同：微服务的部署更加灵活，可以采用多种方式，包括但不限于分布式、集中式或混合式，而分布式系统通常涉及将应用和数据分散到多个服务器上，以实现负载均衡和高可用性
• 通信机制不同：微服务之间通常使用HTTP和RESTful API进行通信，这种通信方式具有良好的跨语言和跨平台兼容性，而在分布式系统中，服务之间的通信可能依赖于更底层的协议，如RPC（远程过程调用）或消息队列
• 数据一致性处理不同：在微服务架构中，每个服务通常负责自己的一部分数据，可以采用最终一致性等较简单的数据一致性处理机制，分布式系统由于数据可能分布在不同的服务中，需要采用特殊的协调机制来确保数据一致性，如分布式事务