seata分布式事务模式选择

1. 业务场景：流程从业务场景开始，作为分析的起点。
2. 是否是长事务：
   • 如果是长事务，建议考虑使用SAGA模式。SAGA模式适用于跨多个服务的长时间事务，通过将大事务拆分为一系列小事务来管理。
3. 并发量如何：
   • 如果不是长事务，接下来需要评估系统的并发量。
   • 高并发：在高并发场景下，建议考虑使用TCC（Try-Confirm-Cancel）模式。TCC模式通过预留资源来保证事务的一致性，适合高并发场景。
   • 低并发：在低并发场景下，继续评估业务的复杂度。
4. 业务复杂度：
   • 简单CRUD：如果业务逻辑主要是简单的增删改查（CRUD），建议考虑使用AT（Automatic Transaction）模式。AT模式通过自动管理事务来简化开发，适合简单的业务场景。
   • 强一致性要求：如果业务对一致性有严格要求，建议考虑使用XA模式。XA模式通过两阶段提交（2PC）来保证强一致性，适合需要严格一致性的场景。

真实业务场景

以下是针对不同事务模式的真实业务场景示例：

---

1. SAGA 模式

SAGA 模式适用于长事务，尤其是跨多个服务的业务场景，通常通过一系列本地事务来实现最终一致性。

• 电商下单流程：用户下单后，需要依次调用库存服务（扣减库存）、订单服务（创建订单）、支付服务（扣款）、物流服务（生成物流单）。如果其中任何一个步骤失败，需要通过补偿操作回滚之前的步骤。
• 机票预订系统：用户预订机票时，需要依次调用航班服务（锁定座位）、支付服务（扣款）、积分服务（扣减积分）。如果支付失败，需要解锁座位并返还积分。
• 酒店预订系统：用户预订酒店时，需要依次调用房态服务（锁定房间）、支付服务（扣款）、优惠券服务（核销优惠券）。如果支付失败，需要释放房间并恢复优惠券。

---

2. TCC 模式

TCC 模式适用于高并发场景，通过预留资源的方式来保证事务的一致性。

真实业务示例：

• 秒杀活动：在秒杀场景中，用户抢购商品时，首先尝试预留库存（Try），如果成功则确认订单（Confirm），如果失败则取消预留（Cancel）。
• 账户余额扣款：在转账或支付场景中，首先冻结账户部分余额（Try），如果扣款成功则确认扣款（Confirm），如果失败则解冻余额（Cancel）。
• 优惠券核销：用户使用优惠券时，首先锁定优惠券（Try），如果支付成功则核销优惠券（Confirm），如果失败则解锁优惠券（Cancel）。

---

3. AT 模式

AT 模式适用于简单的 CRUD 操作，通过自动管理事务来简化开发。

真实业务示例：

• 用户注册：用户注册时，只需要在用户表中插入一条记录，无需复杂的业务逻辑。
• 商品信息更新：商家更新商品信息时，只需要更新商品表中的字段，无需跨服务调用。
• 日志记录：系统记录操作日志时，只需要在日志表中插入一条记录，无需事务补偿。

---

4. XA 模式

XA 模式适用于对强一致性要求极高的场景，通常通过两阶段提交（2PC）来实现。

真实业务示例：

• 银行转账：用户从账户 A 向账户 B 转账时，需要保证账户 A 扣款和账户 B 加款同时成功或同时失败，不能出现中间状态。
• 订单支付：用户支付订单时，需要保证订单状态更新和支付记录写入同时成功或同时失败，不能出现支付成功但订单未更新的情况。