springCloud（二）分布式事务

分布式事务解决方案（TX-LCN）

---

事务特性（ACID）

 A-原子性 C-一致性 I-隔离性 D-持久性

分布式事务理论

CAP理论：分布式系统中，CAP只能保证两个，三个不能兼得。C：一致性，A：可用性，P:容错性。

BASE理论：
    核心思想：系统最终一致性。
    BA：基本可用 S：软状态 E：最终一致性

协调器

XA/JTA规范

XA是两阶段提交事务的规范，JTA是Java实现xa的接口api。atomikos是JTA具体的实现。

两阶段提交协议（2PC）
单JVM，多数据源提交事务

XA/JTA & TCC
XA/JTA:预提交 --> 提交 ==》 rollback
（第一阶段对数据库资源上锁，第二阶段解锁，造成数据库吞吐量的问题）
TCC： try-->confirm-->cancel
程序编码时必须按照三步进行逻辑编码，tcc自定义数据库操作的粒度，解放吞吐量。

***
以一个典型的淘宝订单为例，按照TCC框架，应用需要在Try阶段将商品的库存减去，将买家支付宝账户中的相应金额扣掉，在临时表中记录下商品的数量，订单的金额等信息；另外再编写Confirm的逻辑，即在临时表中删除相关记录，生成订单，告知CRM、物流等系统，等等；以及Cancel逻辑，即恢复库存和买家账户金额，删除临时表相关记录。

JTA框架 atomikos

免费版本实现了JTA/JDBC/JMS

springboot 实现了atomikos

atmikos实现原理

1.每个数据源执行时获取一个标记事务的唯一id
2.每个数据源做execute
3.每个数据源做end，标记这个数据库的sql已经执行完毕，不会再执行别的语句，该事务已经可以提交了
4.每个数据源做prepare，预提交该事务
5.如果所有的prepare都是成功的 则commit否则rollback

---

weblogic

是应用服务器，应用如果部署在weblogic时，可以实现weblogic的控制事务。

TCC

• try

完成所有业务检查（一致性），预留业务资源（相当于隔离性）

• Confirm

确认执行业务操作，不做任务业务检查，只使用try阶段预留的业务资源。

• Cancel

取消try阶段预留的业务资源。

JTA与TCC

JTA单JVM，无法用于微服务，锁表效率低下。

TCC第一步（T）由服务提供预留接口，即将数据通过逻辑锁住；第二步（C）提供确认接口，预留接口返回成功则调用确认接口，真实操作业务；第三步（C）提供取消接口

TCC与XA/JTA的区别

XA是资源层次的分布式事务，强一致性，在两个阶段的提交过程中，一直会持有资源的锁。
TCC是业务层次的分布式事务，最终一致性。

TCC开源框架

Atomikos（收费版 ） , tcc-transaction, springCloud-rest-tcc,支付宝tcc

TCC框架实现原理

TCC框架就是一个协调器，通过try（预留接口）方法自动实现提交与取消操作。
实现@Compensable注解，指定confirm与cancel

可靠消息最终一致性解决方案（rocketMq）

消息生产者发送 预确认消息（prepare） 给消息中间件，之后再执行业务逻辑，业务逻辑执行完毕之后再去发送确认消息（confirm），将之前的 预确认消息中的信息 发送给消费者。如果确认消息发送失败，则可以通过查询预发送消息的状态，根据状态再将预确认消息的信息发送给消费者。

预确认消息中需要类似订单号一类的唯一标示。将预确认状态的消息进行补偿操作。

可靠消息是通过补偿机制做到的。