分布式¶

在互联网早期，单机架构基本能满足访问需求（当时的典型挑战如 C10K 单机并发问题）。然而，随着移动互联网的普及，业务请求量呈指数级爆发，单纯依靠升级单机 CPU 和内存的“纵向扩展（Scale-up）”方案边际收益骤减。由此，通过增加机器节点来实现“水平扩展（Scale-out）”的分布式系统应运而生。

分布式架构在突破性能瓶颈的同时，也引入了一系列复杂的工程挑战，如节点间的数据一致性、系统的高可用性、网络分区容错性以及分布式事务的处理等。这种在分布式环境下的权衡难题，被高度理论化为经典的 CAP 定理（一致性、可用性和分区容错性不可兼得）。

为了解决并驾驭这些分布式难题，业界演进出了丰富的技术生态：例如用于保障多节点状态同步的一致性算法（Raft、Paxos）、处理跨服务数据一致的分布式事务模型（2PC、3PC），以及用于复杂集群资源调度与容灾编排的现代基础设施平台（如 Kubernetes）。此外，区块链技术本质上也是一个具备典型去中心化特征的分布式系统。

在真实的分布式环境中，网络故障（如丢包、延迟、断开连接）是无法彻底避免的常态。因此，CAP 定理在工程实践中的本质指导意义在于：由于分区容错性（P）是必须具备的客观前提，系统设计必须在网络分区发生时，于强一致性（C）和高可用性（A）之间做出取舍。具体而言，对数据准确度零容忍的银行交易、计费等核心系统，宁可拒绝服务也不能记错账，通常倾向于 CP 架构；而社交动态、评论列表、日志收集或 CDN 等追求极致体验的业务，则普遍采用 AP 架构，通过牺牲暂时的强一致性来换取服务的高度可用。