微服务中如何保证数据一致性？

当 A、B、C、D 四个微服务都涉及更新或插入 （写操作）时，由于每个服务有自己的独立数据库，传统的单机事务无法覆盖多个数据库，因此必须采用分布式事务方案来保证数据一致性。

下面我按常见的分布式事务模式来分析，并给出适用场景与示例。

原理：
1. 准备阶段：事务协调者询问所有参与者（A、B、C、D）是否可以提交，参与者锁定资源并返回"就绪"。
2. 提交阶段：如果所有参与者都就绪，协调者发送提交命令；否则发送回滚命令。
优点：强一致性。
缺点：
- 同步阻塞，性能差。
- 协调者单点故障风险。
- 在微服务+多数据库场景下实现复杂，现代应用较少使用（尤其互联网高并发场景）。

适用：传统企业级应用，对一致性要求极高，并发量不大。

原理：将一个长事务拆分为多个本地短事务，每个本地事务完成后发布事件触发下一个本地事务；如果某个本地事务失败，则按相反顺序执行补偿事务（Compensating Transaction）来撤销之前的操作。
两种实现方式：
1. 编排式（Orchestration）：由一个中心协调器（Saga Orchestrator）按顺序调用各服务的本地事务/补偿操作。
2. 协同式（Choreography）：每个服务监听事件，自己决定下一步动作，无中心协调器。
优点：
- 避免全局锁，性能好，适合微服务。
- 最终一致性。
缺点：
- 不保证隔离性（可能出现脏写）。
- 补偿逻辑复杂，有时难以实现（例如物理删除难以补偿）。
适用：高并发互联网微服务，可接受最终一致性。

示例（编排式 Saga） ：

业务：创建订单 → 扣库存 → 扣余额 → 记录物流

原理：将每个服务的方法分为三个阶段：
1. Try：预留业务资源（如冻结库存、预扣金额）。
2. Confirm：确认执行业务操作，使用 Try 阶段预留的资源。
3. Cancel：取消操作，释放 Try 阶段预留的资源。
优点：
- 比 Saga 更可控，可实现类似强一致的效果（通过预留资源）。
- 避免长期资源锁定。
缺点：
- 每个业务都要实现 Try/Confirm/Cancel 接口，开发复杂。
- 对业务侵入性强。
适用：核心金融业务（支付、交易），对一致性要求高且资源可预留。

示例：

订单服务：

原理：
1. 业务执行时，将事件写入本地数据库的消息表（与业务操作在同一事务中）。
2. 后台任务轮询消息表，将未发送的事件发送到消息队列。
3. 消费者服务收到消息后执行本地事务，并确认消息。
4. 如果消费失败，重试或进入死信队列人工处理。
优点：实现相对简单，避免分布式事务框架。
缺点：有数据不一致窗口，依赖消息队列可靠性。
适用：异步场景，允许短暂不一致。

方案	一致性强度	性能	复杂度	适用场景
2PC	强一致	差	中	传统企业应用，低并发
Saga	最终一致	好	中	微服务主流，高并发
TCC	接近强一致	中	高	金融核心业务
本地消息表	最终一致	好	中低	异步、解耦场景

总结：

当 A、B、C、D 都是写操作时，推荐使用 Saga 或 TCC 模式来保证数据一致性，具体选择取决于业务对一致性的要求、性能要求和开发维护成本。