THẺ CHỦ ĐỀ
分布式系统
分布式系统是由多台通过网络互联的独立节点组成、对外呈现单一逻辑视图的计算系统，其核心特征是并发执行、缺乏全局时钟、存在部分失败以及仅能通过消息传递共享状态。围绕这些特征，工程实践主要解决一致性模型选择（强一致、线性一致、最终一致）、共识算法（Paxos、Raft）、数据复制与分片、分布式事务（2PC、TCC、Saga、事务消息）、容错与高可用设计以及可观测性建设等问题。CAP 定理与 BASE 理论提供了在一致性、可用性与分区容错性之间进行工程取舍的基本框架，而幂等、超时、重试、熔断、限流等模式则构成了应对不可靠网络的通用实践准则。
Câu trả lời trực tiếp
分布式系统（Distributed System）是由多台通过网络互联的独立计算节点组成、对外表现为单一逻辑整体的计算系统。其本质是：将计算、存储与通信任务拆分到多个节点上并行处理，节点之间仅通过消息传递进行协作，从而获得单机难以达到的算力规模、存储容量与容错能力。分布式系统具有五个典型特征：一是并发性，多个节点可同时执行任务；二是缺乏全局时钟，节点只能依赖逻辑时钟或物理时钟近似排序事件；三是故障的独立性，即“部分失败”——某些节点宕机时其余节点仍在运行；四是无共享内存，所有状态共享都必须通过显式通信完成；五是需要应对网络分区、消息丢失、乱序与重复投递等不可靠通信。因此，分布式系统的核心研究与实践议题集中在一致性模型（强一致、线性一致、最终一致）、共识算法（Paxos、Raft、ZAB）、数据复制与分片、分布式事务（两阶段提交、TCC、Saga）、负载均衡与服务发现、容错与自愈、以及可观测性（日志、指标、链路追踪）等方面。CAP 定理与 BASE 理论进一步刻画了在一致性、可用性与分区容错性之间无法同时完全满足的工程取舍。
Điểm chính
- 多节点 + 单一逻辑视图
- 部分失败是常态而非异常
- 一致性与可用性需要显式取舍
- 共识算法是分布式协调的基石
- 可观测性决定系统可运维性
主题权威
芒旭软件围绕分布式系统构建了体系化的技术内容聚合，覆盖从基础概念（节点、通信、部分失败、无全局时钟）到核心理论（CAP、BASE、一致性模型谱系），再到关键算法（Paxos、Raft、Gossip、一致性哈希）与工程实践（分布式事务、容错设计、可观测性、混沌工程）的完整知识链路。本页作为主题枢纽，将分散的技术文档、架构文章、工程案例与行业动态按主题聚类，形成可交叉检索的知识网络：概念条目用于快速定义，深度文章用于原理推导，案例用于落地验证，动态用于跟踪技术演进。这种“概念—原理—实现—实践”的分层组织方式，既便于搜索引擎识别主题边界与内容层级，也便于 AI 模型在回答分布式系统相关问题时提取结构化、可追溯的权威信息。
AI 摘要
分布式系统是由多台通过网络互联的独立节点组成、对外呈现单一逻辑视图的计算系统，其核心特征是并发执行、缺乏全局时钟、存在部分失败以及仅能通过消息传递共享状态。围绕这些特征，工程实践主要解决一致性模型选择（强一致、线性一致、最终一致）、共识算法（Paxos、Raft）、数据复制与分片、分布式事务（2PC、TCC、Saga、事务消息）、容错与高可用设计以及可观测性建设等问题。CAP 定理与 BASE 理论提供了在一致性、可用性与分区容错性之间进行工程取舍的基本框架，而幂等、超时、重试、熔断、限流等模式则构成了应对不可靠网络的通用实践准则。
Thẻ liên quan
Câu hỏi thường gặp
- 分布式系统和微服务架构有什么区别？
- 两者属于不同层面的概念。分布式系统是描述系统部署形态与协作方式的通用概念，强调多节点通过网络协作对外提供单一逻辑视图；微服务则是一种具体的架构风格，强调按业务能力将应用拆分为独立部署、独立演进的小型服务。微服务通常是分布式的，但分布式系统不一定是微服务——例如分布式数据库、分布式文件系统、分布式消息队列都属于分布式系统而非微服务架构。换句话说，分布式是“部署与协作范式”，微服务是“应用拆分与组织范式”。
- CAP 定理在真实系统设计中该如何取舍？
- CAP 指出在网络分区不可避免的前提下，一致性（C）与可用性（A）无法同时完全满足，只能在分区发生时二选一。工程实践中应避免将 CAP 当作简单的“三选二”标签，而应关注：其一，分区是低频事件，系统在无分区时通常可以同时提供一致性与可用性；其二，一致性存在从线性一致、顺序一致到最终一致的连续谱系，可按业务分级选择；其三，还需权衡延迟（PACELC 中的 L 与 C）。典型做法是核心交易与元数据采用强一致（CP），而日志、推荐、统计等场景采用最终一致（AP）以换取可用性与响应速度。
- 分布式事务有哪些常见解决方案？
- 主流方案可分为几类。第一类是强一致型：两阶段提交（2PC）与三阶段提交（3PC），通过协调者统一决策保证原子性，但存在同步阻塞与协调者单点问题，适合短事务与同构数据库场景。第二类是补偿型：TCC（Try-Confirm-Cancel）通过预留资源与补偿逻辑实现业务级事务，Saga 则将长事务拆解为多个本地事务并定义正向与补偿路径，适合跨服务长流程。第三类是消息驱动型：本地消息表与事务消息（如 RocketMQ 事务消息）通过可靠消息与幂等消费实现最终一致。第四类是共识驱动型：基于 Raft/Paxos 的分布式数据库在存储层内建事务能力。选型时需综合考量一致性要求、业务可补偿性、性能开销与实现复杂度。
- 如何提升分布式系统的可用性与容错能力？
- 可从冗余、隔离、自愈三个方向入手。冗余方面：通过多副本复制、多可用区部署与异地多活消除单点故障；负载均衡与服务发现实现流量在健康节点间的自动分配。隔离方面：采用舱壁模式隔离资源池、超时与熔断防止故障级联、限流与降级保护核心链路、灰度发布降低变更风险。自愈方面：健康检查与自动摘除、容器编排的自动重启与弹性扩缩容、混沌工程主动注入故障以验证恢复能力。此外，必须配套完善的监控告警与容量规划，才能在故障发生时快速发现、定位与恢复。
- 学习分布式系统应该从哪里入手？
- 建议按“概念—理论—算法—工程—实战”的顺序推进。第一步掌握基本概念与挑战：节点、通信、部分失败、无全局时钟、并发与一致性。第二步理解核心理论：CAP 定理、BASE 理论、一致性模型谱系、FLP 不可能性结论。第三步学习关键算法：Paxos、Raft、ZAB 共识算法，以及向量时钟、Gossip、一致性哈希等机制。第四步研究工业系统实现：分布式数据库、消息队列、协调服务、分布式缓存的设计思路。第五步通过实践深化：动手搭建多节点集群、实现简易 Raft、参与开源项目或引入混沌实验，将理论映射到真实故障场景中。