如何使用最终一致性、CQRS 和事件溯源来实现跨服务的一致性？

Question

Accepted Answer

跨服务时，你通常会用**强**一致性换取**最终**一致性，并依靠 **CQRS** 和**事件溯源**让这种取舍变得切实可行且正确。

## 最终一致性

变更发生后，各副本会“很快”收敛，而非瞬间收敛。这对大多数业务流程是可接受的（库存数量延迟一秒无妨），但对某些场景则不可接受（例如银行余额查询）。

## CQRS（命令查询职责分离）

将**写模型**与一个或多个**读模型**分离。

```text
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
```

读取可以独立于写入进行扩展和重塑；读模型由事件更新，因此它是最终一致的。

## 事件溯源

将**事件序列**作为真相来源（source of truth）来存储，而不仅仅是当前状态。当前状态是对事件序列的一次折叠（fold）。

```text
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
```

## 权衡

| 技术 | 收益 | 成本 |
|---|---|---|
| 最终一致性 | 可用性、可扩展性 | 读到陈旧数据、冲突 |
| CQRS | 读写分别扩展 | 需保持两个模型同步 |
| 事件溯源 | 审计、重放、历史 | 模式/事件演进、复杂度 |

## 陷阱

不要到处都采用事件溯源——它很强大但也很重。只在审计/历史真正重要的地方使用它。

## 为什么这很重要

分布式系统无法同时拥有强一致性、可用性和分区容错性，因此高级设计的关键在于选择哪些地方可以接受最终一致性。

CQRS 和事件溯源为你提供了让最终一致性变得可靠且可审计的工具——但每一个都会带来真实的复杂度，所以要有针对性地应用它们，而不是默认就用。