分布式如何保证一致性(4大常见方案)

分布式是大型架构核心，下面我详解分布式一致性@mikechen

强一致性（强同步协议）

任何一次写成功后，所有后续读都能立刻读到最新数据。

典型特征：

写操作，必须等待多个节点确认；

任一节点不可达，可能直接不可用；

代表方案：两阶段提交（2PC）、三阶段提交（3PC）、Paxos、Raft。

适用场景：金融扣款…等场景。

优点：

读写操作后立即可见一致状态，易于理解和验证。

缺点：

性能开销大，为了保证所有副本都同步。

写操作需要跨网络确认，这会增加延迟（Latency）。

最终一致性（异步复制）

系统在短时间内允许不一致，但在没有新写入的前提下，最终会收敛到一致状态。

也是目前互联网分布式系统中，最常用的方案。

代表方案：异步主从复制、Gossip 协议、基于消息队列的异步同步。

优点：写入延迟低、可用性高（在网络分区时仍能服务），适合高吞吐场景。

缺点：短期内存在数据不一致，需处理冲突和读到旧数据的情况。

弱一致性与可变一致性

系统不保证读操作，一定能读到最新写入的数据。

极度放松约束，强调性能和可用性。常用于缓存或临时数据，不适合持久存储。

常见策略：读写分离、读副本延迟容忍、客户端缓存和版本控制（如向量时钟）。

优点：灵活、可提升性能与可用性。

缺点：增加应用端复杂性，需明确不一致窗口和补偿逻辑。

分区与分片一致性

这不是标准的一致性模型，而是针对数据分区（Partitioning，将数据分成独立部分）。

和分片（Sharding，将分区分布到节点）场景下维护一致性的策略。

重点是跨分区/分片的一致性，确保整体系统视图统一，尽管数据物理分散。

常见做法：跨分区事务使用分布式事务协议（如 XA、基于两阶段提交的全局事务）。

或设计为，最终一致性的补偿型事务（Saga 模式）。

优点/缺点：分布式事务能保证原子性但牺牲性能与可用性；

Saga 等模式通过拆分与补偿提高可用性但增加业务复杂度。