TransactionEssentials

前言 本文主要讲解不同场景下分布式事务的解决方案，以及区别和相关理论。（部分图片来自网络） 一、分布式事务的相关理论 CAP理论： 一致性（Consistency） 可用性（Availability） 分区容错（Partition-tolerance） 一个分布式系统最多只能满足以上的两项，分区容错性是分布式系统必然需要面对和解决的问题，因此在一些大型互联网公司都会把精力放在如何在C（一致性）和A（可用性）之间寻求平衡。 BASE理论 基本可用（Basically Available） 指分布式系统在出现不可预知故障的时候，允许损失部分可用性。 软状态（ Soft State） 指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 最终一致（ Eventual Consistency） 强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。 BASE理论即在整体可用的情况下，满足最终一致性，BASE理论可以说是CAP理论的拓展。 二、分布式事务解决方案 1.跨库事务（强一致性事务） 跨库事务即在一个jvm内调用两个数据库。 XA是由X/Open组织提出的分布式事务的规范

spring mvc 事物失效的原因： 各位侠士都知道，spring事物管理是一个很高大上的东西。 你需要首先了解的知识： 1 msyql 默认的MyISAM引擎是一种 非事务性 的引擎，提供高速存储和检索，以及全文搜索能力，适合数据仓库等查询频繁的应用。 InnoDB则是一种 支持事务的引擎 。所以的数据存储在一个或者多个数据文件中，支持类似于Oracle的锁机制。 所以当你的数据库为默认的存储引擎 MyISAM ，那么你的事物当然不起作用，它不支持事物嘛 2 Spring的事务管理对何种异常进行回滚 Spring的事务管理默认只对出现运行期异常(java.lang.RuntimeException及其子类)进行回滚。 如果一个方法抛出Exception或者Checked异常，Spring事务管理默认不进行回滚。 这就要求我们在自定义异常的时候， 让自定义的异常继承自RuntimeException， 这样抛出的时候才会被Spring默认的事务处理准确处理。 3 入口函数必须是public，否则事务不起作用。这一点由Spring的AOP特性决定的。 4 、如果你使用了springmvc，可能是context:component-scan重复扫描引起的： spring-mvc 只扫描controller 在主容器中（applicationContext.xml）