Java 精通 01：分布式一致性、事务模式与幂等——从理论到可交付方案

本篇目标：能把 CAP 讲成工程取舍；能为订单类业务画状态机；能设计幂等键与去重表；能口述 Outbox 解决的原子性问题；知道至少一次投递下为何必须幂等。

1. 知识点：CAP 的工程读法#

分区发生时：一致性 vs 可用性拉扯。多数互联网业务选择「最终一致 + 可观测补偿」，而不是强行线性一致一切读。

2. 知识点：订单状态机（示例）#

非法迁移返回业务错误码；状态迁移与幂等键同事务写入。

3. 知识点：幂等表（示意 DDL）#

CREATE TABLE idempotency (
  biz_key    VARCHAR(64) PRIMARY KEY,
  response   TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL
);

处理流程：INSERT 幂等键冲突 → 直接返回历史响应；成功则写入响应 JSON。

并发：PRIMARY KEY + 捕获 duplicate key，或用 DB 事务隔离。

4. 知识点：Saga#

长事务拆本地事务 + 补偿：每笔本地事务可提交，失败执行逆操作。要点：补偿也要幂等；状态机记录当前步骤。

5. 知识点：Outbox#

问题：写库成功、发消息失败 → 不一致。

做法：业务事务内写 outbox 表；异步线程扫描 published=false 投递 MQ；成功后标记。

CREATE TABLE outbox (
  id BIGSERIAL PRIMARY KEY,
  payload JSONB NOT NULL,
  published BOOLEAN NOT NULL DEFAULT FALSE,
  created_at TIMESTAMP NOT NULL
);

6. 知识点：消息语义#

7. Lab#

画出「下单→扣库存→支付回调」三状态机；写出幂等键命名规范（bizType + bizId + operation）；伪代码 Outbox 发布器循环。

8. 自测清单#

1. Outbox 相对「先发消息后写库」解决什么？
2. Saga 补偿失败怎么办？
3. 为何不能用 wall clock 做全局顺序？
4. at-least-once + 非幂等 Consumer 会怎样？