目录
1.事务
![](https://i-blog.csdnimg.cn/blog_migrate/7d78bd14bb07e080aa7610922cb78af3.jpeg)
1.1本地事务
![](https://i-blog.csdnimg.cn/blog_migrate/65cfd252e09027f1c8eaab76a33e2e9b.jpeg)
1.2 全局事务
![](https://i-blog.csdnimg.cn/blog_migrate/e987a8e7a0742908de115b58e1a0c0f8.jpeg)
1.3 DTP(全局事务)之二阶段提交协议
13.1 XA接口
XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口,在事务管理器(Transaction Manager)以及一个或多个资源管理器(Resource Manager)之间形成通信桥梁。XA之所以需要引入事务管理器是因为,在分布式系统中,从理论上讲(参考Fischer等的论文),两台机器理论上无法达到一致的状态,需要引入一个单点进行协调。事务管理器控制着全局事务,管理事务生命周期,并协调资源。资源管理器负责控制和管理实际资源(如数据库或JMS队列)
![](https://i-blog.csdnimg.cn/blog_migrate/c1f8d3670c7b6a1811223836b4520ff0.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/080ef12d2065d6d44b284f8581a44119.jpeg)
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应用。
![](https://i-blog.csdnimg.cn/blog_migrate/bcfca5035ad02866edd1773bc0c99f81.jpeg)
JavaEE分布式事务服务利弊
![](https://i-blog.csdnimg.cn/blog_migrate/ec1829341c9535cb29cb6682c3933ebf.jpeg)
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. 柔性事务
![](https://i-blog.csdnimg.cn/blog_migrate/b50ca3dc2165c15918597aa97cdf5f9c.jpeg)
3.1 柔性事务中的服务模式
柔性事务中的服务模式---可查询操作
![](https://i-blog.csdnimg.cn/blog_migrate/77302ba2612ccb59541b6774a58e4f56.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/d7bf08b788009ebf5ee8a39a7f3721fe.jpeg)
柔性事务中的服务模式---TCC操作
![](https://i-blog.csdnimg.cn/blog_migrate/29a4e55b39760a1b1027ec60e0f12d3f.jpeg)
4 柔性事务解决方案
4.1 异步确保性
异步确保型事务(会计记账)(基于可靠消息的最终一致性,可以异步,但数据绝对不能丢,而且一定要记账成功)
将一些同步阻塞的事务操作变为异步的操作,避免对数据库事务的争用,典型例子是热点账户异步记账、批量记账的处理。![](https://i-blog.csdnimg.cn/blog_migrate/58f65e8104b31a6f4080ac94ca4718ff.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/21f45fd521f8509fe65db3b3572e4bff.jpeg)
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文档
![](https://i-blog.csdnimg.cn/blog_migrate/24a5d13feec6b9eb67efbc3676668532.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/50d5b8014228d50744036a55c290962a.jpeg)
4.3 最大努力通知型
![](https://i-blog.csdnimg.cn/blog_migrate/58d93d14a476627218bb6348dd760c89.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/8ff62fe24be810d9509cc84a6445851c.jpeg)