分布式事务的简单介绍

最新推荐文章于 2024-11-27 19:02:54 发布
最新推荐文章于 2024-11-27 19:02:54 发布
阅读量1.7w 收藏
点赞数 1
分类专栏： 分布式 文章标签： 分布式 spring
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/A_Java_Dog/article/details/111771022
版权

java中的事务

java中的事务理解

事务的四个特性ACID

  • 原子性(Atomicity):同生共死 ,要么全部成功,要么全部失败
  • 一致性(Consistency): 相互抵消 (520, -520,对方账户接受+520)
  • 隔离性(Isolation)：并行不扰:并行的两个事物,理论上各个事物,都应该感觉自己是 独占数据库的,但实际上对同一张表进行操作的时候,会出现问题.
  • 持久性(Durability)：落子无悔

事务的隔离级别

隔离级别: 读未提交\读已提交\可重复读\串行化

  • 脏读：事务 a 读取到了事务 b 未提交的结果.
  • 不可重复读：
  • 虚读（幻读）**：例子:用户 a,要给价格>100 且<200 的数据,更新状态,若在第一时间查到 10 条数据; 用户 b,在同一时间删除了添加了条数据, 此时用户 a,查询到 10 条,可是更新了 11 条数据,此时便出现了幻读

脏读和幻读的区别

  • 脏读：一个用户查询到了另一个用户更新的数据但未提交的数据
  • 幻读：一个用户查询到了另个一个插入或者删除但未提交的数据

本地事务

如何实现本地事务?(jdbc\spring)手\自

手动事务的管理\spring 自动管理

编程时事务(手动事务管理)

在JDBC中处理事务，都是通过Connection完成的。同一事务中所有的操作，都在使用同一个Connection对象。JDBC事务默认是开启的，并且是默认提交。

JDBC Connection 接口提供了两种事务模式：自动提交和手工提交

JDBC中的事务java.sql.Connection 的三个方法与事务有关：

setAutoCommit（boolean）:设置是否为自动提交事务，如果true（默认值为true）表示自动提交，也就是每条执行的SQL语句都是一个单独的事务，如果设置为false，需要手动提交事务。

commit（）：提交结束事务。

rollback（）：回滚结束事务。

传统JDBC操作流程：

1).获取JDBC连接 2).声明SQL 3).预编译SQL 4).执行SQL 5).处理结果集

6).释放结果集 7).释放Statement 8).提交事务 9).处理异常并回滚事务 10).释放JDBC连接

JDBC优缺点：1.冗长、重复 2.显示事务控制 3.每个步骤不可获取 4.显示处理受检查异常

JDBC为使用Java进行数据库的事务操作提供了最基本的支持。通过JDBC事务，我们可以将多个SQL语句放到同一个事务中，保证其ACID特性。JDBC事务的主要优点就是API比较简单，可以实现最基本的事务操作，性能也相对较好。但是，JDBC事务有一个局限：一个 JDBC 事务不能跨越多个数据库！所以，如果涉及到多数据库的操作或者分布式场景，JDBC事务就无能为力了。

声明式事务（spring）

spring 利用aop切面进行统一的事务管理，
有两种方式实现：Xml 配置实现\注解方式@Transactionl
在这里插入图片描述
步骤:

  1. 配置数据源
  2. 配置事务管理器,跟数据源匹配
  3. 切面和切入点(决定给哪些业务\什么方法配置事务)
  4. 配置事务通知
  5. 将切入点和事务通知联系起来

分布式事务

事务的参与者\服务器\数据源\事务管理器,分布在不同的节点上.原子性操作,要么
全部成功,要么全部失败.
在这里插入图片描述
事务的参与者\服务器\数据源\事务管理器,分布在不同的节点上.原子性操作,要么全部成功,要么全部失败.
本质:对多个数据源(数据库),保持数据一致性

在这里插入图片描述
本地事务如下图
在这里插入图片描述
分布式事务架构图(解决方法:全局事务管理器)

在这里插入图片描述

分类：

  1. 单一服务分布式事务（单服务-多库）
    在这里插入图片描述
    解决方案:(全局事务管理器 TM)
  2. 分库分表
    数据量大时,分库分表 解决方案: 分库分表中间件:数据库中间件+数据库同步 Mycat
    在这里插入图片描述
多服务多数据源分布式事务

多数据库–多服务:
解决方案:抽取出ap(微服务)\全局事务管理器\数据库资源\以及他们之间的协调者,
共同作用,完成分布式事务管理.

在这里插入图片描述
解决方案的分类
刚性事务:
理论基础:符合ACID 理论的,叫刚性事务(本地事务)
柔性事务:
理论基础:符合(CAP\BASE)理论的事务解决方案,叫柔性事务

在这里插入图片描述

CAP 理论

  • 定义:数据一致性(consistency)、服务可用性(availability)、分区容错性(partitiontolerance)
    结论:三个属性,只能满足其中两个.
    P:分区容错性是必须满足.
    在这里插入图片描述
    C (一致性)：
    A (可用性)：非故障的节点在合理的时间内返回合理的响应.
    合理的时间:三秒钟(合理)\两小时(不合理)
    合理的响应:正在处理,请稍后(合理)\ 出现空指针对象(不合理)
    P (分区容错性)：集群可用性。
    网络无法100% 可靠，分区其实是一个必然现象。p 必须保证
    在这里插入图片描述
    CA 无法保证:
    如果我们选择了CA 而放弃了P，那么当发生分区现象时，为了保证一致性，这个
    时候必须拒绝请求，但是A 又不允许，所以分布式系统理论上不可能选择CA 架
    构，只能选择CP 或者AP 架构。
    CP 应用：Zookeeper 。
    AP 来说，放弃强一致性(这里说的一致性是强一致性)， BASE 理论的基础
    ap 例子：下单,购买了一件商品,不要求马上最库存进行扣减,但只要最终库存扣减即
    可.
    总结:
    CAP：c:一致性a:可用性p:分区容错(集群可用性), cp\ap
    cp 方案： zookeeper
    ap 方案：最终一致性(BASE)理论的基础

BASE 理论

核心思想:

• Basically Available（基本可用） 集群的可用性()
• Soft state（软状态）:比如订单状态:(待付款\已付款\发货\已签收\已结束)
• Eventually consistent（最终一致性）

在这里插入图片描述

柔性事务解决方案(base)

概念:符合BASE 理论的分布式事务解决方案,叫柔性事务解决方案.
1.典型的柔性事务方案如下:(重点)

  1. 2pc,TCC(3pc)（两阶段型、补偿型） 案例:(定婚-领证)
  2. 可靠消息最终一致性（异步确保型）,通过消息队列来保证事务的一致性
  • 非事务型消息中间件(activimq\rabbitmq\kafka)
  • 事务性消息rocketmq(阿里的消息队列)
  • 案例:(在线下棋)
    3)最大努力通知（非可靠消息、定期校对）
  • 案例:滴滴打车有未付款的订单,每个一段时间滴滴都会通知我们付款.
    滴滴最大努力通知用户;用户定期校验.如果未付款,则执行付款,付款后滴滴不再
    重复通知.数据状态保持一致.
    2.举例类比
    2.1 TCC (订婚-结婚) 二阶段2pc(二阶段提交协议) 补偿(回滚)
    订婚,(第一阶段确定)—结婚领证(成功,提交事务\失败,双方回滚事务)
    2.2 通过消息保证事务的最终一致性(在线进行下棋)

在这里插入图片描述
2.3 最大努力通知（非可靠消息、定期校对）
滴滴打车有未付款的订单,每隔一段时间滴滴都会通知我们付款.
滴滴最大努力通知用户;用户定期校验.如果未付款,则执行付款,付款后滴滴不再重复通知.数据状态保持一致.

分布式事务解决方案模型\规范\接口\方案的关系

  1. DTP -----XA-----二阶段提交协议(2pc tcc)
  2. XA ------JTA------atomikos 的关系
  3. 二阶段2pc 与TCC 关系
  4. DTP -----XA-----二阶段提交协议(2pc tcc)
    转载自http://www.tianshouzhi.com/api/tutorials/distributed_transaction

分布式事务处理模型(DTP)标准的提供者.
谁提出来的?
x/open,open group.是一个独立的组织，主要负责制定各种行业技术标准
在这里插入图片描述
1.*模型元素(5 个)
• 应用程序(Application Program ，简称AP)：
• 资源管理器(Resource Manager，简称RM)：如数据库、文件系统等，并提供访问资源的方式。
• 事务管理器(Transaction Manager ，简称TM)：负责分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。
• 通信资源管理器(Communication Resource Manager，简称CRM)：控制一个TM 域(TM domain)内或者跨TM 域的分布式应用之间的通信。
• 通信协议(Communication Protocol，简称CP)：

2.模型实例(Instance of the Model)
在这里插入图片描述

2.1.4 XA 规范

在这里插入图片描述
定义:XA 规范描述如下:XA 规范的最主要的作用是，就是定义了RM-TM 的交互接口，
下图更加清晰了演示了XA 规范在DTP 模型中发挥作用的位置
在这里插入图片描述

2.1.5 XA 规范与二阶段协议的关系

二阶段协议与接口(XA)对比:
二阶段协议:只是协议,一套解决方案:
XA:接口
二阶段提交协议并非在XA 规范中提出来的。但XA 规范定义了两阶段提交协议中需要使用到的接口.
类比:
在这里插入图片描述
总结:
DTP :分布式事务处理的模型
XA: 数据库和tm 之间的接口
xa 和2pc 是相互参考的

2.1.6 二阶段协议和tcc 之间的关系:

二阶段协议:(先讲,2pc 与TCC 区别讲完TCC 后再折回来讲)
类比:订婚和领证的关系
二阶段:定的娃娃亲.(锁整个资源),
TCC:自由恋爱.

在这里插入图片描述
第一阶段。准备阶段
第二阶段:执行阶段commit/rollback
优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用。XA 的性能问题XA 的性能很低。。只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。

总结:
1.XA :接口
二阶段:一组协议,
2.二阶段:
优点: 实现起来相对来说比较简单
缺点: 性能不高.
应用场景:对性能要求不太高,并且要求数据强一致性时,可选择二阶段协议的方案
二阶段

2.1.7 JTA 与xa 及atomikos 的关系

概念:（JTA：Java Transaction Api）:
java 版的xa
某种程度上，可以认为JTA 规范是XA 规范的Java 版，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager 接口，并通过底层事务服务（即JTS）实现。JTA 仅仅定义了接口实现:
• 1.J2EE 容器所提供的JTA 实现(JBoss)商用
• 2.独立的JTA 实现:如JOTM，Atomikos.用于Tomcat,Jetty 以及普通的java应用。
• Atomikos JTA 的实现,用于tomcat,Jetty 等容器
总结:JTA 是xa 的java 实现; Atomikos 是JTA 的一种实现

2.2 补偿事务（TCC）(自由恋爱.)

TCC 是2pc 的一种优化方案: 3pc(三阶段提交)
业务场景:
二阶段:扣减库存(100)100 件都锁死
Tcc: 如果买了两件产品,只锁死2 件,剩余98 个其他事务可以使用.(通过消费记录表)先从库存表中取2 个库存,存到消费记录表中,做了冻结.
如果做第二个阶段成功,提交成功.如果第二个阶段失败了,从消费记录表中取出来,还原给库存表中.
tcc 是二阶段协议的一种,(优化:锁定了一部分资源,剩余的资源,其他的事务可以使用)
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其
对应的确认和补偿（撤销）操作。它分为三个阶段：

  • Try 阶段主要是对业务系统做检测及资源预留
  • Confirm 阶段主要是对业务系统做确认提交，Try 阶段执行成功并开始执行
    Confirm 阶段时，默认Confirm 阶段是不会出错的。即：只要Try 成功，
    Confirm 一定成功。
  • Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
    在这里插入图片描述
    例如： A 要向B 转账，思路大概是：
    我们有一个本地方法，里面依次调用
    1、首先在=Try 阶段，要先调用远程接口把B 和A 的钱给冻结起来。=
    2、在Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
    3、如果第2 步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法(Cancel)。
    优点： 跟2PC 比起来，实现以及流程相对简单了一些，但数据的一致性比2PC 也要差一些
    缺点： 缺点还是比较明显的，在2,3 步中都有可能失败。TCC 属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC 不太好定义及处理。在代码无法完成事务时,可以通过手工干预

总结:
1.TCC (TRY-CONMIT 或者TRY-CANCEL)

  1. 优点:可以再try 阶段,预留一部分资源,使剩余的资源得到释放(与二阶段做比较,
    二阶段在第一阶段锁定资源,所以二阶段的效率低)
  2. 缺点:2 和3 步都可能失败,需要些更多的补偿代码

2.3 通过消息队列保证事务的一致性

本地消息表（异步确保）
本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分
成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出
其中的一些细节：
在这里插入图片描述
具体保存一致性的容错处理如下：
• 当步骤1 处理出错，事务回滚，相当于什么都没发生。
• 当步骤2、步骤3 处理出错，由于未处理的事务消息还是保存在事务发送方，
事务发送方可以定时轮询为超时消息数据，再次发送到消息中间件进行处理。
事务被动方消费事务消息重试处理。
• 如果是业务上的失败，事务被动方可以发消息给事务主动方进行回滚。
• 如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事
务被动方回滚。

基本思路就是：
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ 发送到消息的消费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
这种方案遵循BASE 理论，采用的是最终一致性，笔者认为是这几种方案里面比较适合实际业务场景的，即不会出现像2PC 那样复杂的实现(当调用链很长的时候，2PC 的可用性是非常低的)，也不会像TCC 那样可能出现确认或者回滚不了的情况。
优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

2.4 MQ 事务消息(rocketMQ)

有一些第三方的MQ 是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ 都是不支持事务消息的，比如RabbitMQ 和Kafka 都不支持。
以阿里的RocketMQ 中间件为例，其思路大致为：
第一阶段Prepared 消息，会拿到消息的地址。第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ 会定期扫描消息集群中的事务消息，这时候发现了Prepared 消息，它会向消息发送者确认，所以生产方需要实现一个check 接口，RocketMQ 会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
在这里插入图片描述
异常情况：事务主动方消息恢复

在这里插入图片描述
在这里插入图片描述
容错处理
如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等。
如果是事务被动方业务上的处理失败，可以通过MQ 通知事务主动方进行补偿或者事务回滚。
优点： 实现了最终一致性，不需要依赖本地数据库事务。缺点： 目前主流 MQ 中只有 RocketMQ 支持事务消息。共同点:
特点:都需要自己写业务补偿代码(cancle 代码)
(优点)用消息队列的方式实现分布式事务,效率较高缺点:实现难度较大,和业务耦合比较紧密

Atomikos框架

在这里插入图片描述

4.2.Atomikos的核心步骤(重点)

在这里插入图片描述

4.3.核心步骤:(重点)

Atomikos步骤分析:
1.公共数据源代理的配置
1)配置两个数据源
2)xa数据源统一管理
3)分别配置两个sessionFactoryBean
4)管理各自的mapper
2.配置全局事务管理器
3.将全局事务管理器集成到spring之中
4.切面管理配置和事务通知管理
5.将切入点和事务通知关联起来

Tx-lcn分布式事务框架

http://www.txlcn.org/zh-cn/docs/preface.html

基本概念

1、 什么是LCN框架

LCN分布式事务框架,最新版本v5.0 https://www.txlcn.org
注意点: a. lcn5.0 是使用的注解是@LcnTransaction, 4.0 使用的是
TxTransaction
b. springboot的版本,4.0 使用的是1.5.4 , springcloud版本号和
lcn版本号要相对应的版本

2、框架特点

  1. 支持各种基于spring的db框架
  2. 兼容SpringCloud、Dubbo 3) 使用简单，低依赖，代码完全开源
  3. 基于切面的强一致性事务框架
  4. 高可用，模块可以依赖Dubbo或SpringCloud的集群方式做集群化，
    TxManager也可以做集群化
  5. 支持本地事务和分布式事务共存
  6. 事务补偿机制，服务故障或挂机再启动时可恢复事务

定义:
锁定事务单元（lock）
确认事务模块状态(confirm)
通知事务(notify)
Lcn定位:LCN并不生产事务，LCN只是本地事务的协调工
Lcn的优势:
简单:基于注解 侵入性小

在这里插入图片描述

核心步骤

创建事务组: 发起事务组
加入事务组
通知事务组:

事务参与方都成功

正常执行流程

在这里插入图片描述

出现异常时的时序图

在这里插入图片描述

Tx-client接管数据源
在这里插入图片描述

Lcn
不生产事务,知识本地事务的协调者
核心步骤:
1.事务管理器tx-manager( lcn)
2.注册中心
3.Redis启动
4.发起方核心步骤
(1)Jar包的pom文件管理(lcn\druid)
(2)配置文件:数据源\tm的地址
(3)启动类:注入数据源(使用第三方的数据源做代理,取代了默认数据源) 核心作用:数据库劫持,在事务执行后,假关闭session会话
(4)Mapper配置
(5)通讯模块(发起方2个\参与方1个)
(6)注解@TxTransaction(isStart=true)
5.参与核心步骤
(1)Jar包的pom文件管理(lcn\druid)
(2)配置文件:数据源\tm的地址
(3)启动类:注入数据源(使用第三方的数据源做代理,取代了默认数据源) 核心作用:数据库劫持,在事务执行后,假关闭session会话
(4)Mapper配置
(5)通讯模块(参与方1个)
(6)注解@TxTransaction

未完待续…………… ……………………………………………………………………………………………………………

【分布式事务】一、分布式事务概念、解决方案，一文彻底搞懂分布式事务
技术分享博客，工作经验，技能学习分享（多做一些不会的，会有意向不到的收获，IT高手不可能永远只做会的）
11-06 1169
【分布式事务】分布式事务概念、解决方案，一文彻底搞懂分布式事务
分布式事务（再深入）——分布式事务理论基础 &amp； Java分布式事务解决方案
2401_84254196的博客
04-19 960
刚性事务：分布式理论的CP，遵循ACID，对数据要求强一致性。XA协议是一个基于数据库层面的分布式事务协议，其分为两部分：事务管理器（Transaction Manager）和本地资源管理器（Resource Manager）。事务管理器作为一个全局的调度者，负责对各个本地资源管理器统一号令提交或者回滚。主流的诸如Oracle、MySQL等数据库均已实现了XA接口。二阶提交协议（2PC）: 根据XA协议衍生出来而来;
简单的分布式事务
qq_38384460的博客
04-21 377
1、了解CAP理论 1、一致性 实现目标：当数据分布在多个节点上，从任意节点读取都是最新的数据。 例如：数据库做了读写分离，写入master的数据，要在slave上查询出来的是最新的，也就是一致性 实现方式：当写入主数据库时，将从数据库锁定，等写入完成，解锁从数据库。如果同步失败，返回错误信息 2、可用性 实现目标：从数据库中查询可以立刻查询出结果，不允许出现超时或报错 ...
分布式事务简单处理
武汉红喜
03-09 533
解决分布式事务最简单的方案就是向前或向后，即补充或回滚。业务逻辑有如下三步：调用A服务冻结金额调用B服务增加额度记录数据库进行到第2步失败 -&gt; 写task，回滚第1步(通知A服务方去回滚)进行到第3步失败 -&gt; 写task，从A/B服务处同步数据至数据库还有一种方案就是写task，转化为本地事务，由task去执行上述三步，失败则重试task，当然，A/B服务都有幂等性处理。这种方案的...
这可能是最详细并且简单（啰嗦）的Seata---分布式事务案例
lan_fa_cai的博客
08-31 2590
Seata介绍 2019 年 1 月，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。 Fescar 开源后，蚂蚁金服加入 Fescar 社区参与共建，并在 Fes...
分布式事务解决方案实战
长沙老码农
03-09 2392
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
分布式事务几种解决方案
qq_33449307的博客
05-09 1641
分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 以商品流水账单为例，我们拆分为商品购买系统，订单系统，支付系统。 用户看中一件商品，点击购买。 商品购买系统响应用户的点击，向订单系统插入一条订单信息。
分布式事务的详细介绍。
09-26
**Seata**是一个开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata将事务问题分解为AT（Automatic Transaction）、Saga和TCC模式，为不同场景提供了灵活的选择。在使用Seata时，需要...
分布式事务的介绍
11-09
### 分布式事务的核心概念与实现机制 #### 一、分布式事务概述 分布式事务是指在一个分布式系统中，多个参与节点共同完成的一个业务操作。这些操作要么全部成功，要么全部失败，确保系统的整体一致性。分布式事务...
【项目实战】分布式事务
最新发布
qq_56394739的博客
11-27 1411
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务应该具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
一个简单的分布式事务系统的实现（订单系统）
热门推荐
werflychen的专栏
12-16 1万+
背景：公司最早的一个版本的订单管理，是通过PHP+mysql的方案去实现的，这样会有什么问题呢，假设如果放到一个实例里面，全部用一个单机事务去解决，这样是能比较方便的解决数据一致性问题。但是，无法进行多实例部署，用户量增长以后，无法快速应对，这是第一个版本。之后，我们推出了第二个版本V2，这个版本的时候，我们已经开发好了，库存管理系统，优惠券管理系统，PHP中，已经不直接通过DB去修改库存和优惠券
刚柔并济的开源分布式事务解决方案
ShardingSphere官微
01-25 2092
★作者★张亮，京东数科数据研发负责人，Apache ShardingSphere发起人 & PPMC热爱开源，目前主导开源项目ShardingSphere(原名S...
分布式事务-简单总结
jiang117的专栏
03-18 945
http://blog.sina.com.cn/s/blog_493a8455010167ws.html 可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析: 事务补偿机制 事务补偿即在事务链中的任何一个正
调研 | 5种分布式事务解决方案优缺点对比
BoCloud博云
07-25 8494
背景 分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。 ACID 指数据库事务正确执行的四个基本要素： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） CAP CAP原则又称...
简单说下分布式事务
NasubiZW
10-18 668
1、微服务架构存在的问题有哪些？ （1）分布式系统，进程间的通讯机制和故障处理措施变的更加复杂 （2）系统微服务化后，一个简单的功能，内部可能需要调用多个服务并操作多个数据库实现，产生服务调用的分布式事务问题 （3）微服务数量众多，测试、部署、监控等等运维工作都变的更加困难 2、解决方案 随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springc...
简单的谈一谈分布式事务问题
zw_10254534的博客
01-16 1014
目前，互联网行业的发展，使得系统由单体系统演变分布式系统，传统的集中式蜕变为分布式的。而在分布式系统架构的到来，好处特别多【自行网上搜集资料】，但也带来一个世界性的难题，即分布式事务问题。 何为分布式事务？ 在此，举一个例子【本人开发过程中的经历】： 一个电商系统，采取spring+springMVC+mybatis做基础的技术架构，采用RPC框架做服务的远程调用【Dubbo+zookeep...
分布式事务，原来可以这么玩？
架构师之路
10-16 1215
多个数据要同时操作，如何保证数据的完整性，以及一致性？答：事务，是常见的做法。举个栗子：用户下了一个订单，需要修改余额表，订单表，流水表，于是会有类似的伪代码：start...
java事务运行的并发问题
晚起的鸟儿
12-12 944
  对于同时运行的多个事务，当这些事务访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可归纳为以下几类： 假设数据库中有如下一张表：  •第一类丢失更新(lost update) 在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务异常终止，回滚造成第一个完成的更新也同时丢失。 在T1时刻开启了事务1，T2时刻开启了事务2，在T3...
spring4+mybatis出现AOP方法结束后，事务不释放连接，导致连接数被用完的案例分析
在JAVA的世界中“乘风破浪”
02-27 5131
现象：在进行压测的时候，出现了数据库连接数被用完的情况经过日志分析，发现是因为在一个线程业务启动后，在首次开启事务后，并没有在AOP的方法结束后进行释放，而是一直到线程结束才释放了连接。日志如下图所示：经过分析，一开始以为是出现了锁的问题，但是经过业务上和日志的排查，并没有发现并发死锁的现象。后来排查了Spring AOP的设置，只有propagation的属性为REQURES_NEW和NOT_S...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

意田天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值