关于Saga模式的介绍，已经有一篇文章介绍的很清楚了，链接在这里：分布式事务：Saga模式。
关于TCC模式的介绍，也已经有一篇文章介绍的很清楚了，链接在这里：关于如何实现一个TCC分布式事务框架的一点思考。
1. 子事务动作
Saga的子事务包含两个动作：T和C；TCC的子事务包含三个动作：Try、Commit、Cancel。Saga和TCC相比没有“预留动作”。以经典的A转账给B的例子来说：
Saga：
- T1（A账户余额减少）
- C1（还原A账户余额）
- T2（B账户余额增加）
- C2（还原B账户余额）
TCC
- Try1（A账户余额预扣）
- Commit1（A账户余额减少）
- Cancel1（还原A账户余额）
- Try2（B账户余额预加）
- Commit2（B账户余额增加）
- Cancel2（还原B账户余额）
2. 子事务≠数据库事务
这个需要从两个层面进行展开：
- 首先，无论是Saga还是TCC，一个子事务都包含多个数据库事务。上面的例子中：无论是Saga的T和C，还是TCC的Try、Commit和Cancel，都是一个个完整的数据库事务，天然的具有数据库自身的ACID特性。
- 其次，无论是Saga还是TCC，一个子事务可能并不是数据库操作：比如调用文件服务器进行文件上传、比如发送一封邮件。
3. ACID
这个也需要从两个层面进行展开：
- 首先，从数据库事务层面，在Saga和TCC的中间阶段是不满足一致性（业务逻辑的一致性，而非数据库约束）的
- 其次，从整个分布式事务层面，在Saga和TCC的中间阶段是不满足隔离性的，其他事务可以看到当前事务执行的中间状态
不过以上两个问题都可以通过分布式锁来解决，例如：在执行事务之前对A和B的账户进行加锁，拒绝其他事务的读写操作，但是这样会降低效率。强一致性和高可用性二选一
4. 幂等
关于幂等，要区分子事务是否满足ACID。
- 子事务满足ACID：例如子事务为数据库事务，那么无论是TCC还是Saga，每一个动作都都可以顺利完成或顺利回滚，则不需要幂等性
- 子事务不满足ACID：例如子事务为上传文件， Saga和TCC的T可幂等可不幂等，如果T幂等则可以认为T必定成功则Saga的C和TCC的Cancel不再需要，如果Saga和TCC的T不幂等则Saga的C和TCC的Cancel必须能够处理T部分完成的情况。Saga的C和TCC的Cancel必须幂等，否则当回滚执行失败系统无法确定该再次尝试回滚还是就此放弃。TCC的Commit不存在是否幂等问题，因为按照TCC的规则一旦Try成功则Commit必定成功。