面试题：Spring Cloud微服务架构下的分布式事务处理

TCC（Try - Confirm - Cancel）
- 原理：TCC将事务处理过程分为三个阶段。Try阶段主要是对业务资源进行检测和预留；Confirm阶段在Try成功后，正式执行事务操作，对预留资源进行确认使用；Cancel阶段则是在Try成功但Confirm失败时，对Try阶段预留的资源进行释放回滚。
- 优点：
  - 性能较好，因为Try阶段只需完成部分业务逻辑和资源预留，而不是完整的业务操作。
  - 对业务侵入性相对较小，只要实现对应的Try、Confirm和Cancel接口即可。
- 缺点：
  - 开发成本较高，需要业务开发人员实现三个阶段的业务逻辑。
  - 数据一致性保障依赖Confirm和Cancel操作的幂等性，实现幂等性有一定难度。
Saga
- 原理：Saga模式将一个分布式事务拆分成多个本地事务，每个本地事务都有对应的补偿事务。当其中某个本地事务失败时，会按照顺序调用前面已执行本地事务的补偿事务，以达到事务回滚的目的。
- 优点：
  - 对业务代码的侵入性较小，每个本地事务可以独立开发和管理。
  - 适用于长事务场景，因为它不依赖于长时间的锁机制。
- 缺点：
  - 由于需要实现补偿事务，可能导致代码复杂度增加。
  - 当事务链较长时，故障处理和恢复的逻辑会变得复杂。

业务场景
- 短事务且对一致性要求极高：如果业务场景是类似电商下单扣库存等短事务，且要求强一致性，TCC可能更合适。因为TCC可以通过Try阶段预留资源，快速确认或取消事务，保障数据一致性。
- 长事务且对一致性要求相对宽松：对于一些涉及多个系统交互的长事务，如订单的整个生命周期涉及订单创建、支付、发货等多个环节，Saga模式更适用。它可以允许每个环节的本地事务异步执行，通过补偿事务来最终保证数据一致性。
性能要求
- 高并发低延迟：TCC在高并发低延迟场景下有优势，因为其Try阶段可以快速完成资源预留，在并发量高时能更快响应请求。而Saga模式由于事务链可能较长，在高并发下响应延迟可能相对较高。
- 高吞吐量：如果系统对吞吐量要求高，Saga模式可能更合适。因为它不依赖于全局锁，各个本地事务可以异步执行，能更好地利用系统资源，提高吞吐量。

性能优化
- 异步处理：无论是TCC还是Saga，都可以将一些非关键的操作异步化。例如在TCC的Confirm阶段，如果有一些通知类的操作，可以通过消息队列异步处理，减少主线程的等待时间。在Saga模式中，各个本地事务之间也可以通过消息队列异步触发，提高系统整体性能。
- 缓存应用：在分布式事务涉及的各个服务中合理使用缓存。比如在扣库存操作前，可以先从缓存中读取库存数据进行判断，减少对数据库的直接访问压力，提高事务处理速度。
可用性优化
- 故障恢复机制：对于TCC，要确保Cancel操作的可靠性，即使在网络故障等情况下也能正确回滚。对于Saga，要保证补偿事务的幂等性和可重试性，当某个补偿事务执行失败时，能够自动重试。
- 负载均衡：在高并发场景下，通过负载均衡器将请求均匀分配到各个服务实例上，避免单个实例负载过高导致服务不可用。同时，负载均衡器可以监控服务实例的健康状态，及时将请求从故障实例上转移。
- 熔断与降级：在分布式事务涉及的服务之间设置熔断机制，当某个服务出现故障或响应时间过长时，快速熔断，避免大量请求堆积导致整个系统雪崩。同时，根据业务需求设置降级策略，在服务不可用时提供兜底的处理逻辑，保证系统的基本可用性。

星途面试题库