一.CAP理论筑基

C:Consistency 一致性

强一致性：分布式系统中更新一个数据，各节点数据必须都是一致的。
弱一致性：就是你更新个数据，不管其他节点是否更新成功。
最终一致性：更新数据过后，可能一段时间数据不一致，最后过了一段时间数据一致了。分布式系统的主从同步机制，主节点异步同步给其他节点，就是最终一致性的体现。

A: Availability 可用性

分布式系统必须是可用的，客户端向分布式系统各节点发送请求都是可以获得响应。

P: Partition Tolerence 分区容忍性

分布式系统的网络分区出现故障，各节点之间无法进行通信。但是各节点还是各自运转，依旧能响应请求。

CAP不可能三者兼得，要么CP，要么AP。
分布式系统在网络故障的时候，你写入数据要m节点，此时无法将数据同步到s节点，必然导致m和s的数据不一致。 如果要满足一致性，查询请求过来就返回异常，不让查到不一致的数据，这样就牺牲了可用性。

二.分布式事务常见方案

XA分布式事务，一般用于单系统多数据库场景。

TCC，try-confirm-cancel,适合于同步的服务链调用的事务场景。

可靠消息最终一致性方案，适合于比较耗时的操作，比如调用第三方，通过消息中间件做成异步调用，用MQ消息中间件来保证消息可靠性，最终实现一致性。

最大努力通知方案 和可靠消息方案类似，不过不一定保证成功，适合于一些不太核心的服务调用，比如 发送短信通知

三.TCC方案简述

场景

就项目中订单与库存之间的操作而言，TCC方案比较合适
1.下订单
订单服务
try: 创建订单，订单状态为 初始状态
confirm: 修改订单状态为 待支付
cancel: 修改订单状态为 已取消
库存服务
try: 加锁库存，扣减可销售库存
confirm: 扣减锁库存，加已销售库存
cancel: 扣减锁库存，加可销售库存

下面就对 ByteTcc:ByteTcc官网信息对其整合到实际项目以及相应原理做一些总结:

1.LocalXADataSource bytetcc封装底层的数据源,主要是记录各分布式事务的状态，插入到每个库的bytejta表中
2.@Import(SpringCloudConfiguration.class) 是对spring cloud原生组件进行了一些封装
3.@Compensable注解 主要是将try、confirm、cancel三个接口定义为tcc的三个接口

tcc框架初始化主要做的那些事：

1.CompensableAnnotationValidator 组件扫描有@Compensable注解的bean，并放入一个map中，校验bean中的每个方法是否有@Transactional注解，校验@Compensable注解指定的confirm、cancel service的方法是否标注@Transactional注解。
2.创建了LocalXADataSource对象，并对了创建了动态代理，动态代理的InvocationHandler是ManagedConnectionFactoryHandler
3.ResourAdapterImpl 启动后台一些后台线程任务，
CompensableWork(系统启动恢复事件，以及定时执行恢复)，
CleanupWork(进行一些清理工作),
SampleTransactionLogger(日志记录)

探究一下框架是如何启动一个分布式事务的:

探究tcc报错是如何cancel的:

tcc是如何confirm的:

在try的时候，订单服务调用库存服务，库存服务会被放到resourcelist中，try成功会依次调用resourcelist中服务的confirm操作。如果其中一个confirm没有成功CompensabeWork会每隔60s去执行该confirm，执行成功为止。