这是我参与8月更文挑战的第六天，活动详情查看：8月更文挑战

2pc(一般针对多数据源)

• 准备阶段,这个阶段其实就是执行业务操作.但是业务操作并不提交事务
• 提交/回滚阶段,进行事务的提交和回滚

这里准备阶段就进行了整体业务逻辑的操作.

举例子:银行转账A->B

第一阶段:

​ 访问A,询问是否有30元,如果有就扣除三十元

​ 访问B,增加三十元

第二阶段:

​ 访问A,提交数据库修改

​ 访问B,提交数据库修改

Tcc(一般针对多服务)

TCC 分为三个阶段：

1. Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。
2. Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用 TCC 则认为 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功。若 Confirm 阶段真的出错了，需引入重试机制或人工处理。
3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。

TCC与2PC不同的是,不能保证强一致性(try成功就认定confirm一定成功)

• Tcc这里Try要求的是确保信息资源能够执行后续的Confirm操作.
• 2pc的一阶段其实是执行业务操作,只是不提交

举例子:银行转账A->B

Try:

​ 访问A,判断账户是否存在,账户上是否有三十元,如果有锁定账户余额信息

​ 访问B,判断账户是否存在

confirm:

​ 访问A,扣除三十元,并提交事务

​ 访问B,增加三十元,并提交事务

cancel:

​ 访问A,接触余额锁定

​ 访问B,无

rocketMq如何实现可靠消息最终一致性

最终一致性

1. A服务也就是发送方发送half message 到 broker服务端
2. 当A服务指导半消息发送成功后，开始执行本地事务
3. 执行本地事务会有三种情况(1,执行成功 2，执行失败 3，网络等原因没有响应)
   • 如果执行成功，返回commit
   • 如果执行失败，返回rollback
   • 如果没有收到响应，那么回查事务状态
4. 根据事务的状态执行操作
   • 如果commit，那么提交到订阅方
   • 如果rollback，那么不投递消息，三天后删除
   • 如果没有收到确认，那么回查事务状态