目录
1，事务和分布式事务介绍
2，JTA
3，TCC
事务和分布式事务介绍
之前和一个朋友聊天，聊到工作，他最近在为项目上出现的问题很苦恼，情况我听了之后，就是分布式事务的问题。遂准备许久，整理成文档，与朋友分享。
1，事务：访问数据库的一个操作序列,ACID的特性
2，分布式事务：多个中间件之间的一个操作序列,比如操作了两个数据库，MQ，或许两个不同的系统等等
3，单体应用在一个JVM中，对一个数据库进行CRUD，利用@Transaction就可以保持事务的一致性，如果要对两个数据库进行CRUD,就需要JTA的相关框架，如atomikos，这个是有免费版的；在分布式应用中，就需要TCC的相关框架，如atomikos的收费版，tcc-transaction，支付宝XTC等等
JTA
JTA是标准的两阶段提交，第一个阶段预提交，将提交结果交给协调器，第二个阶段是协调器根据结果，如果两个都是成功那么久commit,否词cancle，在这个过程中会锁表，如果要关联的数据库比较，多，那么JTA时间会很长，会长时间占用资源，效率自然就不高了
TCC
在说TCC之前，首先要了解一下CAP理论
C 一致性 A 可用性 P分区容忍性
这三个中间只能满足两者（外国一个牛人证实的，不信的可以去查，我信），P是一定要满足的，为什么呢？分布式系统，宕掉2三台机器，还要满足能正常运行，这是必须的，所以P就是一定要的了，那么就只有CP或者是AP了，怎么在C和A中间平衡，就是一门艺术了。
BASE理论（柔性事务）的出现很好的平衡了C和A,为什么这么说呢？
BA:基本可用，怎么理解呢？我是这么理解的，比如访问了一次，发现500了，那么刷一下页面好了，这就是基本可用。
S:soft state 软状态，中间状态
E:最终一致，经过中间状态之后，最终要达到最终一致。
TCC是什么呢？
两阶段补偿型方案 try阶段--confirm阶段--cancle阶段
说了这么多理论，解决方案呢？
1，基于MQ的补偿方案，基于MQ，让被调用方都去订阅调用方的消息，消息做重试，幂等，消息中间状态，要说的东西挺多的，画个图：
image.png
解释：1，预发送消息到消息服务中心，消息状态为预发送状态
2，将消息状态由与发送修改为发送
3，消息服务中心，将消息发送到MQ
4，消费方订阅消费消息
这里面有一个中间状态：预发送状态，达到最终一致的补偿机制，这样消息就能可靠的被消费，补偿有很多方式：日志，人工(邮件/短信/Excel)等等
2，TCC两阶段补偿型方案
就拿之前的一个项目案例说明：大学生在线选房，场景是这样的：学生选了床位，还需选择卧具用品。要么床位和卧具都成功，要么都失败。
try阶段：先调用公寓管理系统将床位锁定（预留），在调用仓管锁定预留卧具
confirm阶段：如果两者都预留成功，则提交
cancle阶段：如果有一个预留失败，则取消
====这里不就是JTA吗？===
像但绝对不是，JTA是锁表的，这个没有锁表，所以TCC增加了系统的吞吐量，没有过多的提高单次的执行效率。
看一下tcc-transaction官方文档，恍然大悟了吗？
image.png
其实这个框架就帮我们做了confirm和cancle阶段（第二阶段），将这两个方法写到try方法的头上，就ok了，其他就交给框架吧。
分布式事务重要概念：最终一致，补偿，两阶段提交，中间状态。理解这几个概念，分布式事务也就不难了，其实在我们的实际工作中已经用到了这种分布式事务，我们没有发现而已，总结一下，温故而知新。
望指正，不吝赐教
网友评论