题目
微服务架构下如何保证跨服务数据一致性？
信息
- 类型：问答
- 难度：⭐⭐
考点
分布式事务原理,最终一致性实现,微服务事务模式
快速回答
在微服务架构中保证跨服务数据一致性的核心方案：
- 避免强一致性：优先考虑最终一致性模式
- 常用模式：Saga模式（补偿事务）、TCC（Try-Confirm-Cancel）、可靠事件模式
- 关键机制：事务日志、幂等操作、异步重试
- 辅助工具：消息队列（如Kafka/RabbitMQ）、分布式事务协调器（如Seata）
1. 问题核心挑战
在微服务架构中，传统ACID事务无法跨数据库边界实现，需解决：
- 网络不可靠导致的服务调用失败
- 部分服务成功/部分失败的中间状态
- 高并发下的性能要求
2. 主流解决方案
2.1 Saga模式
原理：将分布式事务拆分为多个本地事务，每个事务提供补偿操作
// 订单创建Saga示例
public class OrderSaga {
// 正向操作
void createOrder() { orderService.create(); }
void reserveInventory() { inventoryService.reserve(); }
void processPayment() { paymentService.charge(); }
// 补偿操作
void cancelOrder() { orderService.cancel(); }
void releaseInventory() { inventoryService.release(); }
void refundPayment() { paymentService.refund(); }
}执行流程：
1. 依次执行 createOrder → reserveInventory → processPayment
2. 若 processPayment 失败，则触发反向链：refundPayment → releaseInventory → cancelOrder
最佳实践：
- 为每个步骤设计幂等操作
- 使用持久化日志记录事务状态
- 设置超时机制和人工干预接口
2.2 TCC模式（Try-Confirm-Cancel）
三阶段流程：
- Try：预留资源（如冻结库存）
- Confirm：提交确认（真实扣减）
- Cancel：取消释放（解冻资源）
// 库存服务TCC接口
public interface InventoryTcc {
@PostMapping("/tryReserve")
boolean tryReserve(Item item); // 冻结库存
@PostMapping("/confirmReserve")
boolean confirmReserve(Item item); // 确认扣除
@PostMapping("/cancelReserve")
boolean cancelReserve(Item item); // 释放冻结
}适用场景：对一致性要求高的金融业务
2.3 可靠事件模式
架构：
（示意图：服务A发布事件 → 消息队列 → 服务B消费事件）
关键实现：
- 事务日志表：在本地事务中记录事件
- 事件发布器：扫描日志并投递到MQ
- 幂等消费：通过唯一ID避免重复处理
3. 方案对比
| 模式 | 一致性强度 | 复杂度 | 适用场景 |
|---|---|---|---|
| Saga | 最终一致 | 中 | 长事务（秒级分钟级） |
| TCC | 强一致 | 高 | 金融交易 |
| 可靠事件 | 最终一致 | 低 | 异步通知场景 |
4. 常见错误
- 过度设计：对一致性要求不高的场景使用TCC
- 忽略幂等性：未处理消息重复导致数据错误
- 缺少监控：未跟踪悬挂事务（如Saga未完成补偿）
- 同步阻塞：在事务链中同步调用导致性能瓶颈
5. 扩展知识
- Seata框架：提供AT模式（自动补偿）和Saga可视化编排
- 消息队列增强：RocketMQ事务消息、Kafka Exactly-Once语义
- CDC技术：通过数据库日志捕获变更（如Debezium）
- 业务妥协：允许短时不一致（如购物车）+ 对账机制修复
