分布式事务协议的背景
近年来，因为微服务解决了我们以往开发中系统可扩展性差以及耦合度高的问题，所以微服务炒得越来越火。一时间各种框架和组件的出现，更是为微服务的开发提供了便利。
微服务是通过多个小服务之间进行组合，来组成更加强大的性能，并且服务间的数据都是独立部署的，避免了单点故障导致全局瘫痪。然而，我们为了解决分布式型事务，二阶段提交协议（2PC）和三阶段提交协议（3PC）也不能很好的满足我们某些场景的需求（比如不能接受事务资源阻塞），于是我们便引出今天TCC分布式事务的话题。
1. 柔性事务TCC简介
柔韧性事务是相对于传统ACID事务的刚而言的。柔性事务只要遵守BASE原则，而TCC是柔性事务的一种实现方式而已。
TCC是2008年的软件开发2.0技术大会上，支付宝的CTO（首席技术官）程立在大规模SOA系统中的分布式事务处理(提取码:166g)中提出来的概念， 作用主要是解决跨服务调用场景下的分布式事务问题。目前市面上免费的开源实现TCC方案的有：tcc-transaction、ByteTCC、spring-cloud-rest-tcc。
2. TCC实现原理
TCC由Try（尝试执行业务）、Confirm（确认执行业务）、Cancel（取消执行业务）三个步骤组成，TCC是取其首字母的简称。
3.TCC的优缺点
-
优点
让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
点评：是个比较大的缺陷，因为就算重新选举一个协调者也无法解决因为上一个协调者故障而导致的参与者处于阻塞状态的问题。 -
缺点
<1>对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
<2>实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等性。
<3>因为confirm和cancel操作有可能失败，而TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
4.幂等性
因为confirm和cancel接口必须实现幂等性，有些同学可能不是很明白这个，这边稍稍做一下普及。
幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
这里需要关注几个重点：
1. 幂等不仅仅只是一次（或多次）请求对资源没有副作用
（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
2. 幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
3. 幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
4. 网络超时等问题，不是幂等的讨论范围。
幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。
