数据安全传输加密与解密

三阶段提交对比两阶段，引入超时机制减少事务阻塞，解决单点故障。在第三阶段，一旦参与者无法接受到协调者信号时，等待超时之后，参与者默认执行 commit，释放资源。

三阶段任然不能解决数据一致性问题。若协调者发出回滚命令，但是由于网络问题，参与者在等待时间内都无法接收到，这时参与者默认提交事务，而其他事务进行了回滚，造成事务不一致。

TCC

TCC 事务

为了解决在事务运行过程中大颗粒度资源锁定的问题，业界提出一种新的事务模型，它是基于业务层面的事务定义。锁粒度完全由业务自己控制。它本质是一种补偿的思路。它把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段的逻辑由业务代码控制。这样就事务的锁粒度可以完全自由控制。业务可以在牺牲隔离性的情况下，获取更高的性能。

TCC 分别为 Trying，Confirm，Cancel 三个单词缩写。不同于 2PC 与 3PC 基于数据库层面，TCC 基于应用层面。TCC 三个动作分别为：

Trying：

• 完成所有业务检查(一致性)
• 预留必须业务资源(准隔离性)

Confirm:

• 真正执行业务
• Confirm操作要满足幂等性

Cancel:

• 释放Try阶段预留的业务资源
• Cancel操作要满足幂等性

上面说法，一听起来有点生涩难懂，没关系我们使用实际案例解释。

下面我们模拟商城一次支付过程。用户下单使用组合支付，即余额加红包支付。一次正常流程为：

1. 创建订单
2. 下单

• 调用余额系统，扣减余额
• 调用红包系统，扣减红包余额
• 修改订单状态为已支付
• 完后支付。
• 实际过程如下图。

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!