tanksyg的专栏

试想一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。**主事务记录 Activity：**主事务记录是整个分布式事务的主体，其最核心的数据结构是事务号（TX_ID）和事务状态（STATE），它是在启动分布式事务的时候持久化写入数据库的，它的状态决定了这笔分布式事务的状态。

6、这时候就会执行最后一个流程，后台守护线程（类似于Redission内部提供一个监控锁的看门狗），来定期的检查锁是否存在，如果存在，延长key的过期时间，还需要判断事务是否还在正常执行，如果是异常已经抛出异常，就不用进行后台守护线程了，然后等待锁自动过期。同时对同一个共享资源（数据库中的一张表或者数据库中的一行数据进行操作），那么这时候就不能采用加锁的方式了，因为多个服务器的内存是不共享的，加锁只能锁住当前服务器的进程和线程，加锁的方式就局限在解决一个虚拟机中的线程安全问题了， 这时候就出现了。

将其更改为： <bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="httpClient"p:requireSecure="false" />这样cas服务端的数据层就完全配置完毕了。--使用MD5加密-->

同步提交事务，查询到当前全局事务下所有的分支事务，通知客户端提交分支事务，如果失败，则将状态更新为 CommitRetrying，由另一个线程反复重试，直到成功为止。这个模块是全局事务管理器，负责开启全局事务、提交全局事务、回滚全局事务、查询全局事务的状态、上报本地事务状态等。3. 执行事务提交操作，异步则是将全局事务状态更新为 AsyncCommitting，更新到数据库，后面由定时任务重新拉起， 执行同步提交事务;这个是资源管理器，负责分支事务注册、分支事务提交、分支事务回滚、锁查询等操作。

ID是数据的唯一标识，传统的做法是利用UUID和数据库的自增ID，在互联网企业中，大部分公司使用的都是Mysql，并且因为需要事务支持，所以通常会使用Innodb存储引擎，UUID太长以及无序，所以并不适合在Innodb中来作为主键，自增ID比较合适，但是随着公司的业务发展，数据量将越来越大，需要对数据进行分表，而分表后，每个表中的数据都会按自己的节奏进行自增，很有可能出现ID冲突。这时就需要一个单独的机制来负责生成唯一ID，生成出来的ID也可以叫做分布式ID，或全局ID。下面来分析各个生成分布式ID的机制