分布式系统

分布式系统是一种** 将计算资源和数据分散在多个独立节点上，通过网络协同完成任务的架构**。在这种系统中，各节点可以相互通信，共同处理客户端请求，实现资源共享和负载均衡。

优点：

可扩展性强，能够灵活增加节点以应对更高的并发和数据处理需求。
容错性高，单个节点故障不会影响整个系统的正常运行。
性能优越，能够分散负载，提高整体处理能力。

缺点：

系统管理和维护复杂，需要处理节点间的通信、同步和一致性问题。
数据一致性难以保证，可能出现分布式事务和数据同步的挑战。
部署和运维成本较高，对网络和硬件资源有更高要求。

CAP定理

CAP定理（CAP Theorem）是分布式系统中的一个重要理论基础。它指出：在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）三个属性无法同时满足，系统设计者必须在这三个属性之间进行权衡，最多只能同时满足其中两个。

Consistency（一致性）：指分布式系统中所有节点的数据保持同步，任何时刻读取数据都能获得最新的值。在一致性系统中，一旦某个节点完成写操作，其他节点立即能读到这个更新。例如：传统关系型数据库通过事务机制确保强一致性。
Availability（可用性）：指系统能够持续为用户提供服务，即使在部分节点故障的情况下。一个可用的系统应该快速响应用户请求，不能无限期地等待。例如：电商平台应该在任何时间都能接受用户的查询和下单请求。
Partition Tolerance（分区容错性）：指分布式系统在网络分区（即节点间通信中断）发生时，仍能继续提供服务。由于分布式系统通常部署在不同的地理位置或网络，网络分区是不可避免的，因此分区容错性是必须的。例如：跨地域部署的系统在网络延迟或中断时应该继续运行。

CAP的权衡

由于CAP三个属性无法同时满足，分布式系统设计必须进行权衡，通常的选择有以下三种：

CA系统（放弃分区容错性）：同时保证一致性和可用性，但无法处理网络分区。这类系统适合单个数据中心环境。例如：传统的关系型数据库（如MySQL集群）在单个数据中心内部署时可以实现CA。
CP系统（放弃可用性）：保证一致性和分区容错性，但在网络分区发生时可能降低可用性。当节点之间无法通信时，系统会拒绝服务以保证数据一致。例如：HBase、MongoDB、Zookeeper等系统优先保证数据一致性，在网络分区时会限制可用性。
AP系统（放弃强一致性）：保证可用性和分区容错性，但牺牲强一致性。系统会在网络分区时继续提供服务，但不能保证所有节点数据实时一致，通常采用最终一致性模型。例如：Cassandra、DynamoDB、DNS等系统都是AP系统，它们优先保证高可用性。

网络分区在分布式系统中不可避免，因此P 是必须满足的，实际选择变成了 CP 或 AP。

示例

假设有一个在线书店，《活着》仅剩 1 本库存，分别在北京、上海两个节点存储。此时网络分区发生，两个节点无法通信。

CP方案（保一致性）：

北京用户下单 → 北京节点无法通知上海节点 → 拒绝请求
结果：用户买不到书，但数据不会出错（无超售）
代价：牺牲了可用性

AP方案（保可用性）：

北京用户下单 → 北京节点返回"下单成功"，库存1→0
上海用户下单 → 上海节点未收到同步，库存仍为1 → 也返回"下单成功"
结果：两人都下单成功，但库存只有1本（出现超售）
代价：暂时不一致，但系统保持可用

TIP

AP系统的补偿机制
AP系统允许暂时不一致，但通过以下机制保证最终一致性：过程：下单（返回软成功）→ 网络恢复后同步数据 → 检测冲突 → 处理冲突 → 达到最终一致

检测阶段：网络恢复，两个节点开始数据同步，发现库存冲突（都显示库存0）
冲突处理：系统按照"先到者优先"原则，保留先提交的订单（如北京用户的订单）
补偿机制：对于后到的订单（上海用户），执行回退操作：取消订单 → 执行退款 → 通知用户重新下单

通过补偿机制，AP系统在保证高可用性的同时，也能达到最终数据一致。

分布式架构类型

分布式系统有多种不同的架构设计方式，主要分为以下两类：

集群架构

集群架构是指将多台服务器（节点）组合在一起，作为一个整体对外提供服务。集群中的各个节点可以相互协作，实现负载均衡和故障转移，从而提升系统的可用性、扩展性和性能。

常见的集群架构模式包括：

主从架构：通过主节点处理写操作，从节点处理读操作，实现读写分离和数据备份
哨兵模式：为主从架构提供自动故障转移能力
分片架构：通过数据分片实现水平扩展

了解更多集群架构 →

微服务架构

微服务架构是将单个大型应用程序分解为多个小型、独立、松耦合的服务组件的架构风格。每个服务通常运行在单独的进程中，通过网络通信进行协作，共同完成业务功能。

微服务架构的核心特征：

独立性强：每个微服务可独立开发、部署、扩展和维护
业务导向：按业务能力而非技术层次进行服务划分
自治性高：微服务拥有自己的数据存储、业务逻辑和通信接口

了解更多微服务架构 →