1. 两阶段提交（2PC）
原理： 2PC是一种阻塞协议，确保所有参与者在事务中要么都提交，要么都回滚。
执行流程：
- 准备阶段：
- 协调者询问所有参与者是否准备好提交。
- 参与者执行事务并返回准备状态（YES/NO）。
- 提交阶段：
- 协调者接收到所有YES则发送提交命令，否则发送回滚命令。
使用方法： 通常用于关系数据库的分布式场景。
优缺点：
- 优点：
- 确保数据一致性。
- 缺点：
- 阻塞性高，参与者可能在等待响应期间被锁定。
- 协调者故障会导致整个事务失败。
使用场景： 适用于对一致性要求高的金融系统等。
2. 三阶段提交（3PC）
原理： 3PC在2PC基础上增加了预提交阶段，减少阻塞风险。
执行流程：
- 准备阶段：
- 协调者询问参与者准备状态。
- 预提交阶段：
- 如果所有参与者准备好，协调者请求预提交。
- 提交阶段：
- 协调者发送最终提交或回滚命令。
使用方法： 适用于对可用性有要求的场景。
优缺点：
- 优点：
- 减少阻塞，能避免长时间等待。
- 缺点：
- 实现复杂度高，协调者和参与者间的通信增加。
使用场景： 适用于实时系统和高可用性服务。
3. 补偿事务（Sagas）
原理： 将长事务拆分为多个小事务，每个小事务都有补偿操作。
执行流程：
- 执行所有小事务。
- 如果某个小事务失败，依次执行已完成的小事务的补偿操作。
使用方法： 通常用于微服务架构中。
优缺点：
- 优点：
- 高可用性，避免长时间锁定。
- 可灵活应对部分失败。
- 缺点：
- 需要设计补偿逻辑，可能会增加开发复杂度。
使用场景： 适用于电商、订单处理等场景。
4. 基于消息队列的事务
原理： 通过消息队列实现异步处理，确保最终一致性。
执行流程：
- 服务处理请求并将消息发送到队列。
- 消费者从队列中读取消息并更新状态。
使用方法： 常用于事件驱动架构。
优缺点：
- 优点：
- 高吞吐量，降低服务间耦合。
- 缺点：
- 消息可能丢失或重复，需要处理这些情况。
使用场景： 适用于高负载和需要异步处理的场景，如日志收集等。
5. TCC（Try-Confirm-Cancel）模式
原理： 每个服务提供尝试、确认和取消操作，确保最终一致性。
执行流程：
- Try：执行业务逻辑并锁定资源。
- Confirm：所有参与者确认执行。
- Cancel：若任一参与者失败，执行取消操作。
使用方法： 适用于需要高一致性的分布式系统。
优缺点：
- 优点：
- 资源锁定时间短，减少阻塞。
- 缺点：
- 实现复杂，需要对业务逻辑进行改造。
使用场景： 适用于需要高可靠性的金融交易和库存管理。
