从集中式到分布式：系统架构与事务一致性演进笔记在系统架构设计中，从集中式到分布式的变迁是应对业务规模增长的重要方向。本文

在系统架构设计中，从集中式到分布式的变迁是应对业务规模增长的重要方向。本文将梳理两种架构的核心特点、分布式环境的挑战，以及事务一致性理论的演进，为学习分布式技术提供清晰脉络。

一、从集中式到分布式：架构模式的转变

集中式系统以中心节点为核心，由一台或多台主计算机组成，数据集中存储于中心节点，所有业务单元也集中部署于此 —— 终端仅负责数据录入与输出，数据存储、控制处理全由主机完成。

其最大优势是部署结构简单：基于高性能大型主机搭建，无需考虑多节点部署与分布式协作问题，适合业务规模较小、需求稳定的场景。

分布式系统的定义是：硬件或软件组件分布在不同网络计算机上，仅通过消息传递实现通信与协调的系统。标准分布式系统（无特定业务约束）具备以下 5 个核心特征：

对等性：无主从节点之分，所有节点地位平等。为保障高可用，会通过 “副本” 实现冗余 —— 数据副本（多节点存储同一份数据，避免数据丢失）、服务副本（多节点提供相同服务，分担请求压力）；

相比集中式，分布式系统因节点分散、依赖网络，会面临更多不可控问题：

了解完架构特点与分布式挑战后，我们聚焦 “事务处理”—— 这是保障数据可靠性的关键，也是分布式与集中式差异显著的领域。

事务（狭义指数据库事务）是：对数据进行访问与更新的操作序列，是程序执行的逻辑单元。它的核心作用有二：隔离并发应用的操作、保障故障后数据一致性。

事务的 4 个核心特征（ACID）如下：

特征	定义
原子性（Atomicity）	操作序列 “要么全成功，要么全失败”，无中间状态
一致性（Consistency）	事务执行前后，数据库始终处于一致状态（如转账后总金额不变）
隔离性（Isolation）	并发事务相互不干扰。SQL 规范定义 4 个隔离级别，不同级别对 “脏读、不可重复读、幻读” 的限制不同（见下表）
持久性（Durability）	事务提交后，数据变更永久生效，不受故障影响

SQL 事务隔离级别与问题对应关系：

隔离级别	脏读	不可重复读	幻读
读未提交（Read Uncommitted）	允许	允许	允许
读已提交（Read Committed）	不允许	允许	允许
可重复读（Repeatable Read）	不允许	不允许	允许
串行化（Serializable）	不允许	不允许	不允许

单机环境中，ACID 易实现；但分布式环境下，数据分散在不同节点，事务需跨数据源 / 业务系统（如跨行转账：本地银行取款 + 目标银行存款），这类事务称为 “分布式事务”，其中的单个操作（取款、存款）称为 “子事务”。

由于子事务分布式执行，要保障全流程 ACID 特性，需解决跨节点通信、故障恢复等问题，难度远高于单机事务。

CAP 理论指出：分布式系统无法同时满足一致性（C）、可用性（A）、分区容错性（P） ，最多满足两项。三者定义如下：

在分布式场景中，“分区容错性（P）” 是必选项（节点分散部署，网络故障不可避免），因此实际需在 C 与 A 间权衡，常见策略如下：

放弃项	说明
放弃 P	所有数据存于单个节点，避免网络分区，但失去可扩展性（非分布式架构）
放弃 A	网络分区时，受影响服务暂停，等待故障恢复（保障数据一致，但牺牲可用性）
放弃 C	放弃强一致性，保留 “最终一致性”：数据不会实时一致，但经过一段时间同步后，最终会达到一致状态（平衡可用性与分区容错性）

BASE 是对 CAP 中 “放弃强一致性” 的补充，核心思想是：通过 “基本可用、弱状态、最终一致性”，实现分布式系统的可用性与一致性平衡。三者定义如下：