分布式事务技术方案.pptxVIP

分布式事务技术方案2012.08.14 Rain目录分布式事务概述JAVA事务背景解决方案参考引用概述简单的说分布式事务就是操作多个数据库之间的事务。在分布式事务管理领域，X/Open的DTP模型是业界最被广泛接受分布式事务管理模型。DTP模型中有一个非常重要的模型，叫Two – Phase Commit Protocol。该协议作用于transaction manager和resource managers之间，保证所有的resource managers要么都commit, 要么都abort。JAVA事务背景Java的事务实现构架遵循了DTP模型,主要有两部分组成:JTS(Java Transaction Service)和JTA(Java Transaction API)。JTS主要规定了DTP模型中transaction manager的实现方式，而JTA则定义了application programs, transaction manager及resource manager之间的接口。JTA可以分为三类， 分别为针对application接口，transaction manager接口和resource manager接口。解决方案一. Spring 分布式事务 1Spring + JOTM 2Spring + ATOMIKOS spring2支持以上1,2两种，但在spring3.0以后spring已经不 支持JOTM，而专注支持ATOMIKOS,主要基于以下考虑： 1JOTM基于XAPOOL，而XAPOOL稳定性比较差 2ATOMIKOS为配置方面比JOTM容易并且其有商业版 本和开源免费版本 …… 二. 自定义程序MQSpring + JOTMSpring + JOTM 关键配置Spring + JOTMSpring + JOTMSpring + JOTM如果使用的是spring3以及3以后的版本需要自己实现JotmFactoryBean,可以直接从spring2.5中拷贝。通过以上配置就在spring中实现了分布式事务处理。 Spring + ATOMIKOSSpring + ATOMIKOS 关键配置Spring + ATOMIKOSSpring + ATOMIKOSSpring + ATOMIKOS自定义程序实现自定义程序实现分布式事务需要自定义XAConnection,XAResource,Xid等，并且需要手动启动，执行，回滚事务自定义程序实现MQMQ方式即补偿事务方式。原理：在需要回滚的事务链中，一旦某个节点出现异常，该节点之前节点事务根据需要灵活进行回滚，在出现异常的节点发消息给前面相关的各个节点Queue通知其回滚本次事务。MQ场景一：单向MQ场景二：分支MQ处理流程：1.一旦某节点事务失败，那么将返回失败消息给前台界面或者HHT，同时发消息给链前面的节点2.前台实时收到返回失败的信息，而链上每个节点都有其监听器在实时监听自己的消息队列，一旦有消息，将根据需要(实时或者非实时)进行处理即回滚前期的事务，但对于前台是透明的。3.Message设计，需要查询到本次链的轨迹，即在链尾或者链叶子节点能查询到该链的各个节点。可以通过唯一的事务ID并且每经过一节点设置其节点位置。Message可以存到数据库或者文件或者其他方式。单向链：开卡队列Message：【事务ID：2012081401,位置:100 …】MQ会员队列Message: 【事务ID：2012081401,位置:200 …】账户队列Message: 【事务ID：2012081401,位置:300 …】分支链:开卡队列Message：【事务ID：2012081402,位置:100 …】会员队列Message: 【事务ID：2012081402,位置:200 …】账户队列Message: 【事务ID：2012081402,位置:310 …】X队列Message: 【事务ID：2012081401,位置:320 …】4.回滚原则： 根据业务需要，确定失败节点前某个或者某些节点需要回滚。 总结分布式事务使用原则：一般尽量避免分布式事务或者优化业务规则来避开分布式事务。除前面的方案，还有EJB，ZOOKEEPER等技术方案也可解决分布式事务，同样类似JBOSS,IBM等厂商均有自己的分布式事务方案。总结各种分布式解决方案对比：技术方案性质技术复杂度性能是否有Demo备注Spring + JOTM开源中待测YSpring3.0后不再支持，必须自己实现或者从spring2.5中拷贝JotmBeanFactory类Spring +ATOMIKOS开源+商业中待测Y由于其开源性质，使其使用广泛，但其商业性质导致后续需要支付一定的服务自定义程序