近两年微服务变得越来越火热，各种框架与组件的出现，更是为微服务的开发提供了便利。
我们都知道，每个微服务都是一个对应的小服务，多个服务之间可以方便的进行功能的组合，来形成功能更强大的服务。服务间数据与部署都是独立的，这样故障也可以做到相互隔离。但是这也带来了分布式应用都会面对的问题：
如何保证多个服务间的事务？怎样才能使操作的原子性、一致性等得到保证？
对于传统的应用开发与部署，可以通过数据的事务来保证所谓的ACID,而微服务的场景下，数据库就力不从心了。
这个时候，2PC、3PC轮番登场，来解决这类的问题。但有些场景下，我们根据自己的真实需要，并不需要纯的2PC，比如你只关心数据的原子性与最终一致性，那2PC阶段的阻塞是你不能忍受的，那就有聪明的人想到了一种新的办法。就是我们今天要说的柔性事务TCC。
什么是柔性事务TCC？
我们今天说的柔性事务，「柔」主要是相对于「传统」ACID的刚而言，柔性事务只需要遵循BASE原则。而TCC是柔性事务的一种实现。TCC是三个首字母，Try-Confirm-Cancel，具体描述是将整个操作分为上面这三步。两个微服务间同时进行Try，在Try的阶段会进行数据的校验，检查，资源的预创建，如果都成功就会分别进行Confirm，如果两者都成功则整个TCC事务完成。如果Confirm时有一个服务有问题，则会转向Cancel，相当于进行Confirm的逆向操作。
整个柔性事务有多种实现的思想，例如：
具体使用
之前的项目开发中，我们也有类似的场景需要保证两个微服务间的一致性，根据具体的场景需要，用到了TCC事务。当时是通过部门的一个基础组件，是通过异步补偿的形式来保证。
目前也有一些开源的TCC实现，可以直接在GitHub上获取到，例如下面这个https://github.com/changmingxie/tcc-transaction
基本实现原理
这些TCC的框架，基本都是通过「注解」的形式，在注解中声明Confirm方法与Cancel方法，再通过AOP对带点该注解的方法统一进行拦截，之后根据结果分别再执行 Confirm 或者 Cancel。
代码类似这个样子：
@Compensable(confirmMethod = "confirmRecord", cancelMethod = "cancelRecord", transactionContextEditor = MethodTransactionContextEditor.class) public String record(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) { |
confirm方法
public void confirmRecord(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {
cancel方法：
public void cancelRecord(TransactionContext transactionContext, RedPacketTradeOrderDto tradeOrderDto) {
基于类似的框架，可以比较方便的满足我们的业务使用场景。欢迎留言补充你在分布式的场景中是通过什么方式来保证一致性的。
补充说明:
文中图片来源于「支付宝架构与技术」文档，感兴趣的朋友可以自行搜索获取该文件。
