分布式事务 以及 JTA TCC

     微服务相对于单体应用来说，将单一程序开发为一组小型服务，服务之间根据http轻量级通讯机制调用，单个服务独立开发，独立选型技术，独立部署和运维。方便服务扩展。随着微服务架构的使用，分布式集群所带来的问题也应运而生，如 分布式事务。

数据库事务

   数据库事务，事务不再累赘，最主要的四大特征：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。 数据库由两部分组成，数据库文件和日志文件，在进行curd时候，先进行日志操作，然后在进行数据库操作，这种方式可以保证数据库由于本地数据库断电时候的数据一致性，根据日志，在重启时候进行回滚或者前滚，保证数据强一致性。

而关系型数据库事务ACID（Atomicity原子性[要么全完成，要么全失败]，Consistancy一致性[事务前后状态一致]，Isolation隔离性[事务只能在各自数据库]，Durablity持久性[一旦提交，不能返回]），满足高一致性和可用性 ，无法满足分区。

 

分布式事务

在数据库集群中，集群数据库事务的ACID难以满足，所以需要使用新的理论CAP 、base理论来满足集群数据库，例如多库之间的事务问题，和多个服务之间的事务问题。

cap原理和base原理

分布式领域cap原理：

分布式系统无法满足以下三点 ，最多只能满足CAP中的两种。

​ Consistancy(一致性)，数据一致性，所有数据的变动都是一致的。

​ Availability(可用性)，好的响应性能。​

 Partition tolerance(分区容错)，分区可靠性。

然而数据库的任何扩展操作都要依赖于分区，所以开发人员只能在一致性和可用性上面做出选择。

base理论：

base Avaliable(基本可用)、soft state （软状态）、Eventually consistent（最终一致性）。牺牲一致性，强调高可用性。即使无法做到强一致性，但是每个应用可以根据自身业务的特点，采取适当的方式使系统达到最终一致性。

软状态： 允许系统存在中间状态，并认为系统的中间状态不影响系统的整体可用性，即允许数据副本在不同节点之间的同步过程存在延时。

2pc与JTA

以mysql数据库为例，在进行亿万级数据进行建表时，进行分库，分表设计。后端服务对分库数据库进行更新时，单个服务调用两个库A B，如果数据库A更新成功，而数据库B更新失败时，造成数据不一致，事务失败。这是一种单个服务对多个库进行更新的情况。这种情况可以使用2pc(两阶段提交)模式， 而JTA事务支持2pc，

JTA是提供分布式事务接口，提供跨数据库连接的事务管理，Bitronix是一个流行的开源JTA事务管理器实现。JTA是J2EE中的接口，专门用于解决多数据库的数据一致性。

两阶段提交（Two Phase Commit，下文简称2PC），简单的说，是将事务的提交操作分成了prepare、commit两个阶段。其事务处理方式为：1、 在全局事务决定提交时，a）逐个向RM发送prepare请求；b）若所有RM都返回OK，则逐个发送commit请求最终提交事务；否则，逐个发送rollback请求来回滚事务；2、 在全局事务决定回滚时，直接逐个发送rollback请求即可，不必分阶段。

举个栗子，在购买商品的服务中，用户购买商品，会调用两个库，库A用户资金库，库B商品库，在使用2pc的过程中，

2pc

首先第一阶段（准备阶段）： AB  两个库准备，A库冻结一部分资金用于购买，并通知事务，库B准备部分商品也通知事务管理器；

第二阶段（提交or回滚）： 假如两个库都准备success后，则事务管理器就进行提交，否则进行回滚。

注意的是：2PC机制需要RM提供底层支持（一般是兼容XA），而下面的TCC机制则不需要。

 

TCC

而对于两个服务之间的分布式事务问题，例如，一个业务调用两个服务，两个服务之间的事务问题，可以使用TCC (Try-confirm-cancle),补偿提交，实现最终一致性。

• TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可.

• TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行。

  相对于TCC来说，JTA是一种比较笨重的接口，但TCC,实现难度较大。

 

针对分布式事务，还可以使用消息队列。