分布式事务中TCC、SAGA 或可靠消息事务应该如何理解？
TCC、SAGA 和 可靠消息事务 是分布式事务中的三种常见模式，它们通常用于解决分布式系统中的一致性问题。它们与 2PC（两阶段提交）相比，通常会在性能和可扩展性上有所优化，适用于不需要强一致性的场景。
1. TCC（Try-Confirm/Cancel）事务
TCC 是一种 三阶段提交 模式，适用于 高可用、高并发的分布式系统，尤其是像 支付、预订等场景，它通过三步操作来协调分布式事务。
TCC 主要步骤：
-
Try：尝试执行操作，通常是预留资源、扣减库存等。此时，操作被锁定，但并没有提交。
- 例如：用户下单时，商家锁定商品库存。
-
Confirm：确认操作，只有当所有参与者的 Try 阶段都成功执行时，Confirm 才会执行，真正提交操作。
- 例如：用户付款成功后，商家正式扣除库存，并生成订单。
-
Cancel：取消操作，当某个参与者的 Try 阶段失败或业务逻辑异常时，需要执行取消操作，撤回之前的预留操作。
- 例如：支付失败时，商家需要取消库存锁定或退款。
TCC 的优点：
- 可以保证操作的 一致性 和 原子性，不像 2PC 那样需要长时间锁住资源。
- 适用于高并发、分布式场景。
TCC 的缺点：
- 需要事先定义好 Try、Confirm 和 Cancel 的操作逻辑。
- 一旦操作失败，需要额外的补偿机制来恢复状态。
TCC 举例：
假设一个电商系统的用户下单并支付，涉及到 库存服务、订单服务 和 支付服务。
- Try：库存服务预留库存、订单服务创建订单，支付服务扣款。
- Confirm：所有服务都执行确认提交，完成库存扣除、订单生成和支付扣款。
- Cancel：如果支付失败，支付服务执行退款，库存服务释放库存，订单服务删除订单。
2. SAGA（补偿事务）
SAGA 是另一种分布式事务模型，它通过将一个长事务拆分成多个独立的子事务来解决分布式事务问题。每个子事务执行后会提交，并在发生错误时通过 补偿事务 来进行回滚。
SAGA 模式有两种实现方式：
- Choreography（编排）：每个子事务之间通过事件驱动的方式进行协作，没有集中协调者。各个服务自己知道如何处理自己的事务和补偿操作。
- Orchestration（协调）：有一个中心协调者来调度所有子事务的执行。如果某个子事务失败，协调者会执行相应的补偿操作。
SAGA 的步骤：
- 执行子事务：每个子事务执行时，都会对资源做出变更。
- 补偿操作：如果某个子事务失败，执行补偿操作（例如回滚前面的操作）。
SAGA 的优点：
- 每个子事务都是局部事务，执行失败时可以通过补偿来恢复状态，减少全局锁持有时间。
- 适用于长事务，操作步骤可以更灵活。
SAGA 的缺点：
- 需要设计复杂的补偿机制。
- 可能存在 长时间的并发冲突，需要协调子事务的顺序。
SAGA 举例：
在一个订单支付流程中，假设有如下三个服务：库存服务、订单服务 和 支付服务。
- 第一步：库存服务扣除库存。
- 第二步：订单服务创建订单。
- 第三步：支付服务处理支付。
- 补偿操作：
- 如果支付失败，则支付服务会退款，库存服务会恢复库存。
- 如果库存扣除失败，订单和支付服务需要做补偿操作，恢复状态。
3. 可靠消息事务
可靠消息事务 主要通过消息队列和 最终一致性 来解决分布式事务的问题。它通过异步消息传递来确保操作的成功，并利用消息队列的 消息补偿 机制来确保消息的可靠性。
可靠消息事务的基本步骤：
- 发送消息：事务服务通过消息队列发送消息，通知其他服务执行某项操作（如扣库存、生成订单等）。
- 接收消息：接收方服务接收到消息后执行相应的业务逻辑。
- 消息补偿：如果某个环节出现失败，消息队列会重新发送消息，直到操作成功。
可靠消息事务的特点：
- 最终一致性：所有操作会在一段时间内达到一致状态，但在此之前，数据可能会不一致。
- 异步执行：服务之间通过异步消息进行通信，不会阻塞主流程。
可靠消息事务的优点：
- 相比 2PC 和 TCC，性能较高，没有全局锁定操作，适合高并发场景。
- 实现简单，可以利用现有的消息队列（如 Kafka、RabbitMQ）来实现。
可靠消息事务的缺点：
- 只能保证 最终一致性，不适合对强一致性要求高的场景。
- 消息的 丢失 和 重复消费 需要通过额外的机制来处理。
可靠消息事务举例：
例如一个电商平台中的订单创建和支付过程：
- 消息发送：订单服务在用户下单后，向消息队列发送扣除库存的消息。
- 消息消费：库存服务接收到消息，扣除库存并返回成功消息。
- 消息补偿：如果库存服务执行失败，消息队列会重新发送消息直到成功。
4. 总结
| 事务模型 | 主要特点 | 优缺点 | 适用场景 |
|---|---|---|---|
| TCC | 三阶段提交，包含 Try、Confirm、Cancel 操作。用于高可用场景，适合需要强一致性的业务。 | 优：强一致性、业务逻辑清晰；缺：需要实现 Try/Confirm/Cancel 操作，业务复杂。 | 支付、预订等高一致性要求的业务 |
| SAGA | 将长事务拆分为多个子事务，每个子事务失败时执行补偿操作。 | 优：支持长事务、灵活的补偿操作；缺：设计复杂、可能产生长时间的并发冲突。 | 电商订单、支付等长事务的业务 |
| 可靠消息事务 | 通过消息队列进行异步消息传递，利用消息补偿机制确保最终一致性。 | 优：高并发、实现简单；缺：只能保证最终一致性，适用场景有限。 | 高并发、消息驱动的异步事务系统（如电商平台） |
每种事务模型适用于不同的场景，TCC 适用于对一致性要求高的业务，SAGA 适用于长事务和补偿操作，可靠消息事务适用于高并发的分布式环境。如果你在开发过程中有类似需求，可以选择合适的模型进行实现。