事务的原子性就是不能有中间状态的存在，要么成功，要么失败。两阶段提交正好有一个中间状态——准备成功。 如果全局事务数据丢失，协调者是不是可以向所有资源管理者发送状态询问消息，如果资源管理者存在中间状态，则让他们都回滚或提交。 如果采取上面说的办法，那么就需要解决的如何匹配两个处于“准备成功”状态的账户是属于同一笔交易的问题了，即找到一个“破损交易的另一半”。 所以，应该在交易将要开始前，在每个资源管理者本地的数据库中记录全局交易的ID，这样就可以把N个处于中间状态的账户关联起来了。这样相当于把协调者的全局数据在资源管理者出“冗余”了一份。有了这个信息，协调者又可以愉快的玩耍了： 1、如果两个关联账户都处于“准备成功”状态，那么让它们都会滚。 2.1、如果一个处于已提交状态，一个处于“准备成功”状态，则进行补偿，让后者变为成功状态。 2.2、如果这和业务需求不符合，则两者都提交后，再发起一笔反向交易，将状态都修改为交易之前的状态。

银行间跨行转账如何实现一致性的，毕竟A行不能直接操作B行数据，是调用B服务

疑问： TCC在cancel阶段也可能失败，那怎么办？感觉这里是个悖论，通知节点cancel，但cancel本身也可能失败，那就每完没了了，反复尝试，直至成功cancel吗？

用分布式数据库自身的快照日志和事务日志相结合能倒推出来吧

在第一阶段，协调者向所有参与的数据库发送准备提交的消息。每个数据库在收到协调者的消息之后，对自己本地的数据库进行预处理，比如给数据加锁、修改数据等等。如果预处理成功，本地数据库返回准备成功的消息给协调者。如果预处理失败，则返回准备失败的消息。请注意，这时候本地的数据库事务还没有完成，也就是既没有提交事务，也没有回滚事务。 你有没有发现一个悖论？对于在第一阶段操作成功了的数据库来说，这些操作已经提交了，那已经提交了的事务怎么可能在第二阶段回滚呢？事务不是要求已经提交的事务不能回滚吗？ 这两段话应该怎么理解呢？第一阶段产生的事务提交了？

事件溯源的分布式系统如何实现分布式事务？

“TCC 情况下的跨机器转账”这个案例中，其实阶段1也要求一个一致性，数据库A和全局事物管理器的一致性，TCC阶段1内部这里也可以采用2PC来实现。

“在单机版和两阶段提交的情况下，数据库隐藏了所有上面这些中间细节，因此你会感觉事务有原子性。但是在 TCC 的情况下，由于业务系统控制了分布式事务的进程，这些中间状态会暴露给业务系统，因此你才能感受到一些临时的不一致状态。”2PC、3PC、TCC的概念其实已经再熟悉不过了，但是感觉这句话感觉老师有自己的东西，果断买课。

前面的课程老师有教过通过记录事件，在需要回溯时，通过回放一段时间事件的方法来得到某个指标的最后状态，我想协调者也可以通过这种方法来得到最后状态，协调者的数据库是记录事物的最后的状态，在协调事件的发生过程中涉及到事件可以通过WAL方式记录写入磁盘中，协调者DB不能用时，协调者可以通过向前追溯未完事件ID的方法来得到当前还未完成事物的各方所处阶段。 当然还可以通过共识算法来达成一至，但这就超出了2PC和TCC的范畴了。