强一致性 弱一致性 最终一致性 -元一软件

一致性问题产生

分布式为了保证高可用就衍生了多副本或多节点, 为了保证某一时间修改了一个节点的数据其他都要保持一致,就有了一致性问题

一致性通俗讲解

先前提：一致性问题只出现在分布式系统（数据存在多台服务器 / 多个副本）。 一份数据复制到多个节点，当更新数据后，不同节点什么时候能看到最新数据，就是一致性要解决的事。

1. 强一致性（Strong Consistency）

数据更新完成后，所有节点立刻同时看到最新版本的数据。 只要写操作成功返回，之后任意客户端去任意节点查询，拿到的一定是新数据，不存在旧数据。

1.1形象例子

银行转账：A 转给 B 100 元。转账成功之后，任何人查询 A、B 账户，必须马上看到余额变化，绝不允许一会儿查到转账前、一会儿转账后。

1.2特点

✅ 数据永远统一,金融等核心业务必要条件，无脏读 ❌ 性能差、延迟高；必须等待所有副本同步完成才返回结果；故障容易阻塞业务

1.3强一致性算法

Raft 算法 应用：etcd

Paxos 算法（Basic Paxos / Multi-Paxos） 应用：Google Spanner、Chubby、OceanBase

ZAB 协议（ZooKeeper 专属） Zookeeper 依靠 ZAB 实现强一致，分布式锁。

1.4数据库主从【同步复制】

MySQL 半同步复制（after sync）、PostgreSQL 同步流复制 必须等待 binlog/wal 日志发送到从库并且落盘，主库才响应客户端

⚠️注意：普通异步主从不是强一致！只有同步复制才是

1.5分布式事务（保证跨数据强一致）

• 2PC（两阶段提交）：传统分布式事务，强一致，性能差（Seata AT 模式底层思想）

• 3PC：优化 2PC 阻塞问题，落地较少

---

1. 最终一致性（Eventual Consistency）

2.1定义

属于弱一致性的特例，增加一条保证：在没有新写入的前提下，经过一段时间，所有副本最终一定会同步到相同数据。 短暂不一致是允许的，但系统最终会收敛一致。

2.2关键点：

更新后短时间内，不同客户端读到的数据可能不一样；

如果不再写入新数据，足够长时间后，所有节点数据必然一致。

2.3特点

✅ 性能均衡，互联网主流方案 ❌ 存在短暂数据不一致窗口

2.5各类示例

Redis（默认异步主从、哨兵、集群异步复制）

Elasticsearch：分片副本异步同步

MQ（RocketMQ/Kafka）+ 消费者同步多端数据 举例：订单创建后，发 MQ 异步更新商品销量、消息队列异步数据同步方案（业务层实现最终一致）

2.6多活 / 异地多活常用方案

数据双向异步同步（例如 MySQL binlog 同步、DTS 数据同步工具）

3.一张对比总结

3.1容易混淆的关键点

最终一致性 ≠ 强一致性：中间存在不一致窗口期；

最终一致性属于弱一致性，工程上习惯分开讲，因为最终一致性有收敛保证；

CAP 理论：分布式系统中，强一致性 C 和高可用 A 很多时候无法同时完美兼顾，互联网业务大多牺牲即时一致性，选择最终一致性换取高可用。

3.1 补充延伸

业界还会经常见到：

• 顺序一致性、因果一致性：介于强一致和最终一致中间；

• 读写一致性（会话一致性）：同一个用户会话内，自己总能读到自己刚写入的数据，是最终一致性的优化版本（比如淘宝购物车）。

如果你需要，我可以举一段伪代码演示三种一致性在读、写时的行为差异。

3.2 Seata的模式

Seata 4 种模式：AT、TCC、XA、SAGA。

先给核心结论（金融业务面试标准答案）：

1. AT 模式 = 最终一致性（互联网最常用，CAP 里偏向 AP）

2. XA 模式 = 强一致性（CP，数据库原生 2PC）

3. TCC：业务层补偿型最终一致

4. SAGA：长流程最终一致

金融业务不能一概而论，分为【资金核心交易】和【金融辅助业务】两套选型。

4.金融业务Seata

AT 一阶段直接提交本地事务！ 举例：A 扣钱的 SQL 执行完毕，本地事务提交，余额已经变少，只是记录 undo_log。 此时全局事务还没最终确认，外部查询已经能看到账户余额变动（中间态数据可见）。

• 属于最终一致性

• 存在短暂数据不一致窗口

• 资金核心场景（转账、账户扣款）大厂核心账务系统一般不直接裸用 AT

• ⚠️注意：核心业务一定要要求强一致性

4.1核心资金链路（账户转账、余额扣减、清算、出金入金）

✅ 优先方案：TCC 原因： TCC 采用资源预留思想

• Try：冻结资金（不是直接扣钱）

• Confirm：真正扣款

• Cancel：解冻资金 全程不会出现 “钱凭空消失” 的中间状态，外部看不到半成品账务，资金风险可控。 适合：跨微服务账户转账、支付资金划转。

备选：XA 模式 XA 是数据库原生强一致 2PC，真正强一致性； 缺点：长时间持有行锁，并发差、容易阻塞，高并发金融系统很少用 XA，一般低并发内部账务使用。

❌ 不推荐直接使用 AT 做核心资金交易 风险：全局事务二阶段阻塞时，资金已经扣掉，还没完成对手账户入账，外部查询余额异常，容易引发资损、对账不平。

4.2金融辅助业务（非资金核心链路）

例子： 生成订单记录、交易流水日志、积分变动、消息通知、风控快照、理财产品浏览统计。 👉 可以使用 AT 模式 特点：就算短暂不一致，不会直接造成资金损失，事后可以对账修复。

4.3：长流程金融业务（保险理赔、分期放款、多方审批流程）

👉 SAGA 模式 流程很长，持续几分钟 / 小时，无法长期锁住资源，依靠正向事务 + 反向补偿。

5金融业务选型问题

5.1金融转账能不能用 Seata AT？

理论功能上能跑，但是生产资金核心链路不建议。 AT 一阶段直接更新余额，产生可见的中间状态；一旦 TC 故障卡住，容易出现单边账风险。 资金交易标准选型是 TCC；非资金流水、日志类业务可以用 AT。

5.2AT 属于 AP 吗？

CAP 角度理解： AT 为了高可用、高性能，放弃实时强一致，属于 AP 系统思路（最终一致性） XA 追求强一致，代价是可用性下降，属于 CP 思路。 ⚠️ 只是思路类比，不要说 “Seata AP 模式”，术语错误！

5.2极简对比表

5.4单边账问题讲解

⚠️ 扣款成功，入账失败（最常见的单边账）

A 所在账户服务执行扣款，数据库更新余额成功；

紧接着网络断开、服务宕机、TC 故障，B 的入账逻辑始终没有执行； 结果：A 少了 100 元，B 余额没变。 钱凭空消失，平台平白多出 100 元资产，属于资损事故。

⚠️ 入账成功，扣款失败

A 没扣钱，B 账户多了 100 元，用户白拿钱，平台亏损。 这两种不对称的账务，统称为单边账。

6、行业真实落地经验

很多互联网支付公司做法：

1. 核心资金账务：自研 TCC / Seata TCC

2. 订单、交易记录、报表数据：Seata AT

3. 同时配套定时对账任务，兜底修复一切分布式不一致问题（金融必备！任何分布式事务都不能替代对账）