分布式事务系列（三）：TCC和本地消息表

Martin Fowler在他的文章中解释了“微服务架构”的主要思想和原则

https://gist.github.com/yulewei/1240ad4ee486c6e61f7178263cf09fe4https://gist.github.com/yulewei/1240ad4ee486c6e61f7178263cf09fe4

采用微服务架构的应用程序越来越多，围绕微服务产生的安全性、事务原子性、可靠性等问题的讨论越来越重要。

TCC架构

TCC事务其实主要包含两个阶段：Try阶段、Confirm/Cancel阶段。其中Try阶段完成业务检查并资源预留，确保在Confirm阶段资源可用，可以最大程度的确保confirm阶段能够执行成功。

 TCC模式对程序的代码侵入性很高，需要分布式事务的参与者（资源管理器）提供Try、Confirm和Cancel三个方法，并且Confirm和Cancel方法必须保证调用的幂等性。事务协调者接收各个事务参与者的执行结果，并根据执行结果决定执行Confirm方法或Cancel方法。

Try方法：

1.执行业务检查

2.进行资源预留

Try方法检查各个事物参与者是否满足执行业务逻辑所需要的资源，满足时需要进行资源预留，确保Confirm方法一定能够执行成功，并且向事务协调者TC上报Try阶段的执行结果。

Confirm方法

1.执行真正的业务逻辑

2.只使用Try阶段预留的业务资源

3.Confirm操作必须保证幂等性

只要全部事务参与者（资源管理器）的Try方法能够执行成功，Confirm方法大概率是会执行成功的。因此在Confirm阶段就需要事务协调者TC进行不断重试，确保所有事务参与者的Confirm方法能够执行成功。此时已经没有回头路可走了，只能一头撞在南墙上不断重试比头铁！

Cancel方法

1.释放Try阶段预留的资源

2.Cancel操作必须保证幂等性

部分或全部事务参与者（资源管理器）的Try方法执行失败，由于Try阶段进行了资源预留，这部分预留的资源需要在Cancel方法中释放。因此Cancel阶段就需要事务协调者TC进行不断重试，确保Try阶段执行成功的事务参与者的Cancel方法能够执行成功从而释放Try阶段预留的资源。此时也没有回头路可走了，只能一头撞在南墙上不断重试比头铁！