目录
1.事务
1.1本地事务
1.2 全局事务
1.3 DTP（全局事务）之二阶段提交协议
13.1 XA接口
XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）
X/Open DTP（Distributed Transaction Process）是一个分布式事务模型，此模型主要使用二阶段提交（2PC，Two-Phase-Commit）来保证分布式事务的完整性。在这个模型里面，有三个角色：
-
AP：Application，应用程序，业务层。
-
RM：Resource Manager，资源管理器，关系型数据库或支持 XA 接口（XA 规范是 X/Open 组织定义的分布式事务规范）的组件。
-
TM： Transaction Manager ，事务管理器，负责各个 RM 的提交和回滚。
当应用程序（AP）调用了事务管理器（TM）的提交方法时，事务的提交分为两个阶段实行。
第一阶段（准备阶段）
TM 通知所有参与事务的各个 RM，给每个 RM 发送 prepare 消息。
RM 接收到消息后进入准备阶段后，要么直接返回失败，要么创建并执行本地事务，写本地事务日志（redo 和 undo 日志），但是 不提交（此处只保留最后一步耗时最少的提交操作给第二阶段执行）。
第二阶段（提交 / 回滚阶段）
TM 收到 RM 准备阶段的失败消息或者获取 RM 返回消息超时，则直接给 RM 发送回滚（rollback）消息，否则发送提交（commit）消息。
RM 根据 TM 的指令执行提交或者回滚，执行完成后释放所有事务处理过程中使用的锁（最后阶段释放锁）。
二阶段提交的利弊
优点
2PC 提供了一套完整的分布式事务的解决方案，遵循事务严格的 ACID 特性。
缺点
-
TM 通过 XA 接口与各个 RM 之间进行数据交互，从第一阶段的准备阶段，业务所涉及的数据就被锁定，并且锁定跨越整个提交流程。在高并发和涉及业务模块较多的情况下对数据库的性能影响较大。
-
二阶段是 反可伸缩模式 的，业务规模越大，涉及模块越多，局限性越大，系统可伸缩性越差。
-
在技术栈比较杂的分布式应用中，存储组件有很多 不支持 XA 协议。
二阶段的诸多弊端，导致分布式系统下无法直接使用此方案来解决数据一致性问题，但它提供了解决分布式系统下数据一致性问题的思路。。
1.3.2 JTA规范
作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种：
1.J2EE容器所提供的JTA实现(JBoss)
2.独立的JTA实现:如JOTM，Atomikos.这些实现可以应用在那些不使用J2EE应用服务器的环境里用以提供分布事事务保证。如Tomcat,Jetty以及普通的java应用。
JavaEE分布式事务服务利弊
2. BASE理论和CAP理论
2.1 ACID
关系型数据库具有解决复杂事务场景的能力，关系型数据库的事务满足 ACID 的特性。
-
Atomicity：原子性（要么都做，要么都不做）
-
Consistency：一致性（数据库只有一个状态，不存在未确定状态）
-
Isolation：隔离性（事务之间互不干扰）
-
Durability： 永久性（事务一旦提交，数据库记录永久不变）
具有 ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。
然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足 ACID，我们就需要寻找微服务架构下的数据一致性解决方案。
微服务架构的系统本身是一种分布式系统，而本文讨论的问题其实也就是分布式事务之数据一致性的问题，我们来聊聊分布式系统的 CAP 理论和 BASE 理论。
2.2 CAP
CAP 是指在一个分布式系统下， 包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且 三者不可得兼。
-
C：Consistency，一致性，所有数据变动都是同步的。
-
A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。
-
P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。
关系型数据库 单节点 保证了数据强一致性（C）和可用性（A），但是却无法保证分区容错性（P）。
然而在分布式系统下，为了保证模块的分区容错性（P），只能在数据强一致性（C）和可用性（A）之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。
BASE 理论主要是解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题。BASE 理论包含以下三个要素：
-
BA：Basically Available，基本可用。
-
S：Soft State，软状态，状态可以有一段时间不同步。
-
E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。
BASE 模型与 ACID 不同，满足 CAP 理论，通过 牺牲强一致性来保证系统可用性。由于牺牲了强一致性，系统在处理请求的过程中，数据可以存在短时的不一致。
系统在处理业务时，记录每一步的临时状态。当出现异常时，根据状态判断是否继续处理请求或者退回原始状态，从而达到数据的最终一致。
例如，在上面的案例中，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些 补偿方法 来让积分得以正确地增加。后面会讲到具体的实现方法。
3. 柔性事务
3.1 柔性事务中的服务模式
柔性事务中的服务模式---可查询操作
柔性事务中的服务模式---TCC操作
解决
4 柔性事务解决方案
4.1 异步确保性
异步确保型事务(会计记账)（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）
将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用，典型例子是热点账户异步记账、批量记账的处理。
4.2 TCC补偿型
这是分布式环境下事务处理的典型模式。
补偿型：
TCC型事务（Try/Confirm/Cancel）可以归为补偿型。
补偿型的例子，在一个长事务（ long-running ）中 ，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。
例子来源：OASIS的WS-BusinessActivity文档
4.3 最大努力通知型
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
