微服务架构下不使用2PC如何实现分布式事务一致性？

针对你这套混合SQL/NoSQL、松耦合要求高、还要扛住各种故障的分布式架构，以下几个模式是目前最实用的：

1. Saga模式：本地事务+补偿回滚 #

把跨服务的“类事务”拆成一串独立的本地ACID事务，每个微服务只管好自己的那一步，出问题就反向补偿。

• 两种落地方式：
  • 无中心编排：各服务靠事件触发联动，比如支付成功后发「支付完成」事件，库存服务收到就执行扣减；要是库存扣减失败，它发「库存扣减失败」事件，支付服务收到就给用户退款。完全松耦合，每个服务只盯着自己关心的事件。
  • 中心编排：搞个专门的协调服务（比如订单协调器），统一调度流程：先调用支付服务收钱，成功后再调用库存服务扣货，哪一步失败了就通知前面的服务做补偿。适合流程复杂的场景，方便统一管控。
• 适配混合数据库：不管是SQL还是NoSQL，只要能给每个操作写对应的补偿逻辑（比如NoSQL里把扣减的库存加回去）就行。
• 故障应对：给所有操作加幂等校验（比如用唯一订单ID做标识，重复请求直接返回成功），配合消息重试、死信队列，就算服务崩了、网络断了，恢复后也能接着处理。

2. 最终一致性+事件驱动 #

靠事件传递保证最终所有服务数据对齐，不用强求实时一致，适合大部分电商、物流这类业务场景。

• 事件溯源：每个服务的状态变化都存成事件，比如支付服务不直接改「已支付」状态，而是存一条「用户XXX支付订单XXX成功」的事件；库存服务订阅这个事件，自己去更新库存状态。就算某个服务挂了，事件存在消息队列里，等它活过来再处理就行。
• 搭配CQRS：把写操作（比如扣库存）和读操作（比如查库存剩余）分开，写操作只产生事件，读操作从专门的视图库拿数据，既避免读写冲突，又能分别对读写环节扩缩容，性能和扩展性都能拉满。
• 优势：服务间完全靠事件通信，没有直接调用，松耦合程度极高；不管是SQL还是NoSQL服务，只要能处理事件更新自身数据就兼容。

3. 本地消息表：解决事件丢包问题 #

这是个可靠投递的“土办法”，但实用性极强，专门对付「本地事务成功了，但事件没发出去」的情况。

• 流程：支付服务收钱的时候，在本地数据库（SQL表或NoSQL集合）里同时插一条「待发送支付成功事件」的记录；然后开个后台线程，不停扫这个表，把事件往消息总线发；发成功了就删掉这条记录，发失败就重试。库存服务收到事件后，先执行本地扣库存的事务，成功了就给个确认，支付服务收到确认再删消息。
• 适配混合数据库：SQL用本地表存消息，NoSQL用自身持久化能力存，只要能保证「写业务数据+写消息」是原子操作（比如SQL的事务、NoSQL的原子写入）就行。
• 故障应对：消息存在本地，就算服务崩了，重启后线程接着发；库存服务处理失败的话，消息会自动重试，实在不行进死信队列留待人工处理。

4. TCC模式：预锁定+确认/取消 #

适合那些需要先占住资源再最终确认的场景，比如支付、库存扣减这类对资源管控要求高的业务。

• 分三个阶段执行：
  • Try：先锁定资源，比如支付服务预扣用户余额，库存服务锁定要扣的库存，这一步不提交最终状态。
  • Confirm：所有服务的Try都成功了，就执行确认操作，比如把预扣的余额真正扣掉，把锁定的库存删掉。
  • Cancel：只要有一个服务Try失败，就取消所有操作，把锁定的资源释放（比如给用户退预扣的钱，把库存加回去）。
• 注意：每个服务得实现这三个接口，而且都要做幂等校验；不管是SQL还是NoSQL，只要能实现资源锁定和释放逻辑就行。

必加的可靠性保障措施 #

不管用哪种模式，这几点是底线：

• 幂等性：所有操作（包括补偿、重试）都要做到重复执行不搞乱数据，比如用唯一请求ID当标识。
• 重试机制：失败的操作/事件要重试，用指数退避策略（比如第一次等1秒，第二次等2秒，以此类推），避免给服务造成过大压力。
• 死信队列：重试多次还失败的事件，扔进死信队列，别占着消息总线，留待人工排查处理。
• 状态监控：把每个跨服务流程的状态盯紧，出问题及时告警，别等用户找上门才发现异常。

内容的提问来源于stack exchange，提问作者James Delay