下面是tcc事物的介绍

一个TCC事务框架需要解决的当然是分布式事务的管理。关于TCC事务机制的介绍，可以参考TCC事务机制简介。
TCC事务模型虽然说起来简单，然而要基于TCC实现一个通用的分布式事务框架，却比它看上去要复杂的多，不只是简单的调用一下Confirm/Cancel业务就可以了的。

下文将以Spring容器为例，试图分析一下，实现一个通用的TCC分布式事务框架需要注意的一些问题。

一、TCC全局事务必须基于RM本地事务来实现全局事务

TCC服务是由Try/Confirm/Cancel业务构成的，其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource Manager，下文简称RM）来存取数据。这些存取操作，必须要参与RM本地事务，以使其更改的数据要么全部commit，要么全部rollback。

这一点不难理解，考虑一下如下场景：

假设图中的服务B没有基于RM本地事务（以RDBS为例，可通过设置auto-commit为true来模拟），那么一旦[B:Try]操作中途执行出错，TCC事务框架后续决定回滚全局事务时，该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB：如果[B:Try]业务有5个写库操作，[B:Cancel]业务则需要逐个判断这5个操作是否生效，并将生效的操作执行反向操作。

不幸的是，由于[B:Cancel]业务也有n（0<=n<=5）个反向的写库操作，此时一旦[B:Cancel]也中途出错，则后续的[B:Cancel]执行任务更加繁重。因为，相比第一次[B:Cancel]操作，后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n（0<=n<=5）个写库中哪几个已经执行、哪几个还没有执行，这就涉及到了幂等性问题。

然而，对幂等性的保障，很可能也需要涉及额外的写库操作，该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。

可想而知，如果不基于RM本地事务，TCC事务框架是无法有效的管理TCC全局事务的。

反之，基于RM本地事务的TCC事务，这种情况则会很容易处理：[B:Try]操作中途执行失败，TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时，在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下，根本无需执行[B:Cancel]操作。

换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的Cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。

二、TCC事务框架应该接管Spring容器的TransactionManager

基于RM本地事务的TCC事务框架，可以将各Try/Confirm/Cancel业务看着一个原子服务：一个RM本地事务提交，参与该RM本地事务的所有Try/Confirm/Cancel业务操作都生效；反之，则都不生效。

掌握每个RM本地事务的状态以及它们与Try/Confirm/Cancel业务方法之间的对应关系，以此为基础，TCC事务框架才能有效的构建TCC全局事务。

TCC服务的Try/Confirm/Cancel业务方法在RM上的数据存取操作，其RM本地事务是由Spring容器的PlatformTransactionManager来commit/rollback的，TCC事务框架想要了解RM本地事务的状态，只能通过接管Spring的事务管理器功能。

2.1. 为什么TCC事务框架需要掌握RM本地事务的状态？
首先，根据TCC机制的定义，TCC事务是通过执行Cancel业务来达到回滚效果的。仔细分析一下，这里暗含一个事实：只有生效的Try业务操作才需要执行对应的Cancel业务操作。换句话说，只有Try业务操作所参与的RM本地事务被commit了，后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作；否则，如果Try业务操作所参与的RM本地事务被rollback了，后续TCC全局事务回滚时就不能执行其Cancel业务，此时若盲目执行Cancel业务反而会导致数据不一致。

其次，Confirm/Cancel业务操作必须保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作，其参与的RM本地事务也必须被commit。TCC事务框架需要在确切的知道所有Confirm/Cancel业务操作参与的RM本地事务都被成功commit后，才能将标记该TCC全局事务为完成。如果TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的状态，就会造成全局事务不一致。

最后，未完成的TCC全局，TCC事务框架必须重新尝试提交/回滚操作。重试时会再次调用各TCC服务的Confirm/Cancel业务方法。如果某个服务的Confirm/Cancel业务之前已经生效（其参与的RM本地事务已经提交），重试时就不应该再次被调用。否则，其Confirm/Cancel业务方法被多次调用，就会有“服务幂等性”的问题。

2.2. 拦截TCC服务的Try/Confirm/Cancel业务方法的执行，根据其异常信息可否知道其RM本地事务是否commit/rollback了呢？
基本上很难做到。为什么这么说呢？

第一，事务是可以在多个（本地/远程）服务之间互相传播其事务上下文的，一个业务方法（Try/Confirm/Cancel）执行完毕并不一定会触发当前事务的commit/rollback操作。比如，被传播事务上下文的业务方法，在它开始执行时，容器并不会为其创建新的事务，而是它的调用方参与的事务，使得二者操作在同一个事务中；同样，在它执行完毕时，容器也不会提交/回滚它参与的事务的。因此，这类业务方法上的异常情况并不能反映他们是否生效。不接管Spring的TransactionManager，就无法了解事务于何时被创建，也无法了解它于何时被提交/回滚。

第二、一个业务方法可能会包含多个RM本地事务。比如：A(REQUIRED)->B(REQUIRES_NEW)->C(REQUIRED)，这种情况下，A服务所参与的RM本地事务被提交时，B服务和C服务参与的RM本地事务则可能会被回滚。

第三、并不是抛出了异常的业务方法，其参与的事务就回滚了。Spring容器的声明式事务定义了两类异常，其事务完成方向都不一样：系统异常（一般为Unchecked异常，默认事务完成方向是rollback）、应用异常（一般为Checked异常，默认事务完成方向是commit）。二者的事务完成方向又可以通过@Transactional配置显式的指定，如rollbackFor/noRollbackFor等。

第四、Spring容器还支持使用setRollbackOnly的方式显式的控制事务完成方向；

最后、自行拦截业务方法的拦截器和Spring的事务处理的拦截器还会存在执行先后、拦截范围不同等问题。例如，如果自行拦截器执行在前，就会出现业务方法虽然已经执行完毕但此时其参与的RM本地事务还没有commit/rollback。

TCC事务框架的定位应该是一个TransactionManager，其职责是负责commit/rollback事务。而一个事务应该被commit还是被rollback，则应该是由Spring容器来决定的：Spring决定提交事务时，会调用TransactionManager来完成commit操作；Spring决定回滚事务时，会调用TransactionManager来完成rollback操作。

接管Spring容器的TransactionManager，TCC事务框架可以明确的得到Spring的事务性指令，并管理Spring容器中各服务的RM本地事务。否则，如果通过自行拦截的机制，则使得业务系统存在TCC事务处理、RM本地事务处理两套事务处理逻辑，二者互不通信，各行其是。这种情况下要协调TCC全局事务，基本上可以说是缘木求鱼，本地事务尚且无法管理，更何谈管理分布式事务？

三、TCC事务框架应该具备故障恢复机制

一个TCC事务框架，若是没有故障恢复的保障，是不成其为分布式事务框架的。

分布式事务管理框架的职责，不是做出全局事务提交/回滚的指令，而是管理全局事务提交/回滚的过程。它需要能够协调多个RM资源、多个节点的分支事务，保证它们按全局事务的完成方向各自完成自己的分支事务。

这一点，是不容易做到的。因为，实际应用中，会有各种故障出现，很多都会造成事务的中断，从而使得统一提交/回滚全局事务的目标不能达到，甚至出现”一部分分支事务已经提交，而另一部分分支事务则已回滚”的情况。

比较常见的故障，比如：业务系统服务器宕机、重启；数据库服务器宕机、重启；网络故障；断电等。这些故障可能单独发生，也可能会同时发生。作为分布式事务框架，应该具备相应的故障恢复机制，无视这些故障的影响是不负责任的做法。

一个完整的分布式事务框架，应该保障即使在最严苛的条件下也能保证全局事务的一致性，而不是只能在最理想的环境下才能提供这种保障。退一步说，如果能有所谓“理想的环境”，那也无需使用分布式事务了。

TCC事务框架要支持故障恢复，就必须记录相应的事务日志。事务日志是故障恢复的基础和前提，它记录了事务的各项数据。TCC事务框架做故障恢复时，可以根据事务日志的数据将中断的事务恢复至正确的状态，并在此基础上继续执行先前未完成的提交/回滚操作。… 阅读全文

在研究cas的过程中， 发现cas的部署项目是采用overlay方式部署的， 因此上网查找如下：

在一个大项目中拆分maven工程时，很有可能会把js、css、jsp等文件放在不同的工程里（根据业务模块划分）。因为如果都集中在一个maven webapp里，那么这个maven webapp会太大，而且在业务上也比较分散

但是这些持有js、css、jsp的maven工程，如果packaging设置为jar是不合适的，因为外围要读取内部的这些文件就会很困难。在这种场景下，一个很自然的想法就是打成war包，然后用某种方式将多个war包归并起来，得到最终的war包

这就是overlays发挥作用的地方

以下举一个例子：

这里有2个web工程，一个是task-sla-web，一个是task-web-dist，packaging类型都是war，目录结构如下：

下面是task-sla-web的pom文件：
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-sla-web</name>

该工程就是打成一个war包，但是这个war是无法运行的，而是稍后用来合并的。（其中放了 一个空的web.xml，因为maven-war-plugin的package goal有强制要求）

下面是task-web-dist的pom文件：
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-web-dist</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-web-dist</name>

Xml代码 收藏代码
<!– 合并多个war –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>… 阅读全文

介绍

Feign是从Netflix中分离出来的轻量级项目，能够在类接口上添加注释，成为一个REST API 客户端。

Feign中对 Hystrix 有依赖关系。Feign只是一个便利的rest框架，简化调用，最后还是通过ribbon在注册服务器中找到服务实例，然后对请求进行分配。

实际项目

在入口程序中添加注释

@EnableFeignClients

REST API 客户端

@FeignClient(value = "ticket-service", configuration = YeaFeignConfiguration.class,fallback = TicketClientHystrix.class)
interface TicketClient {

    @RequestMapping(method = RequestMethod.POST, value = "/create")
    Message<String> create(
            @RequestParam(value = "Type"

• 首先，对于一个web应用，其部署在web容器中，web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的spring IoC容器提供宿主环境；
• 其次，在web.xml中会提供有contextLoaderListener。在web容器启动时，会触发容器初始化事件，此时contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，spring会初始化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext，这是一个接口类，确切的说，其实际的实现类是XmlWebApplicationContext。这个就是spring的IoC容器，其对应的Bean定义的配置由web.xml中的context-param标签指定。在这个IoC容器初始化完毕后，spring以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE为属性Key，将其存储到ServletContext中，便于获取；
• 再次，contextLoaderListener监听器初始化完毕后，开始初始化web.xml中配置的Servlet，这个servlet可以配置多个，以最常见的DispatcherServlet为例，这个servlet实际上是一个标准的前端控制器，用以转发、匹配、处理每个servlet请求。DispatcherServlet上下文在初始化的时候会建立自己的IoC上下文，用以持有spring mvc相关的bean。在建立DispatcherServlet自己的IoC上下文时，会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文。有了这个parent上下文之后，再初始化自己持有的上下文。这个DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到，大概的工作就是初始化处理器映射、视图解析等。这个servlet自己持有的上下文默认实现类也是mlWebApplicationContext。初始化完毕后，spring以与servlet的名字相关(此处不是简单的以servlet名为Key，而是通过一些转换，具体可自行查看源码)的属性为属性Key，也将其存到ServletContext中，以便后续使用。这样每个servlet就持有自己的上下文，即拥有自己独立的bean空间，同时各个servlet共享相同的bean，即根上下文(第2步中初始化的上下文)定义的那些bean。

一、先说ServletContext

javaee标准规定了，servlet容器需要在应用项目启动时，给应用项目初始化一个ServletContext作为公共环境容器存放公共信息。ServletContext中的信息都是由容器提供的。

举例：

<context-param>
   <param-name>key</param-name>
   <param-value>value123</param-value>
</context-param>
<listener> 
   <listener-class>com.brolanda.contextlistener.listener.ContextListenerTest</listener-class>
</listener>

package com.brolanda.contextlistener.listener;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class ContextListenerTest