微服务架构中的数据一致性

微服务架构将单体应用拆分为独立部署的服务，带来了开发效率和系统可扩展性的提升，但同时也引入了数据一致性的挑战。分布式事务、最终一致性、事件驱动……这些概念在实际项目中该如何取舍？

问题的本质

在单体应用中，我们依赖数据库事务保证 ACID。但微服务架构下，每个服务拥有独立的数据库，跨服务的数据变更无法用本地事务覆盖。经典的例子：电商下单需要同时扣减库存、创建订单、增加积分，这三个操作分布在三个服务中。

两阶段提交是最严格的方案，但同步阻塞、单点故障、性能开销大，在微服务场景中几乎不被采用。

业务层面的分布式事务方案，需要为每个操作实现 Try/Confirm/Cancel 三个接口。适合资金类强一致性场景，但开发成本高。

这是目前最主流的方案。核心思路是：本地事务 + 消息表 + 可靠消息投递。通过本地消息表保证业务操作和消息发送的原子性，消费者通过幂等保证不会重复处理。

将长事务拆分为多个本地事务，每个步骤有对应的补偿操作。适合流程长、参与方多的业务场景。编排式 Saga 通过状态机驱动，更加直观。

数据一致性没有银弹，关键是根据业务场景选择合适的方案，在一致性和可用性之间找到平衡点。