1.分布式事务产生的原因

来源于微服务、分布式系统之间跨数据库产生的问题,数据库做垂直分割(按照业务需求划分数据库、分库),分为多个不同的数据源(JDBC连接),会产生分布式事务的问题。

在微服务环境下,因为会根据不同的业务会拆分成不同的服务,比如会员服务、订单服务、商品服务等,让专业的人做专业的事情,每个服务都有自己独立的数据库,并且是独立运行,互不影响。

服务与服务之间通讯采用RPC远程调用技术,但是每个服务中都有自己独立的数据源,即自己独立的本地事务。两个服务相互通讯的时候,两个本地事务互不影响,从而出现分布式事务产生的原因。

2.分布式事务产生的场景

订单服务、库存服务。服务之间的调用接口的时候会产生分布式事务的问题,服务之间的调用走的是http协议进行通讯的。

流程图:

分布式事务解决方案_数据

 

3.Spring事务和分布式事务的区别?

Spring事务是本地事务。

分布式事务是需要跨服务进行通讯的。

4.如何区分分布式事务

不同的JDBC连接,下图是一个分布式事务场景。虽然二个服务连接的是同一个数据库,但是它们有各自的JDBC连接,所以属于分布式事务。

分布式事务解决方案_数据_02

5.分布式事务解决方案

 5.1 使用Jta+Automatic 只适合传统项目。

 5.2 消息中间件MQ,底层通过Base理论 柔性事务解决

 5.3 2PC(二段提交协议)、3PC

 5.4 TCC补偿、GTS 属于阿里产品

 5.5  TX-LCN框架

5.6 支付回调方式(重试机制+补偿机制)

核心原理:LCN并不生产事务,LCN只是本地事务的协调工。

LCN官网:​​http://www.txlcn.org/zh-cn/​

6.基本的事务概念

原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),ACID原则,这种特性也成 刚性事务。

博客:​​javascript:void(0)​

7.base理论

BASE理论是指,Basically Available(基本可用)、Soft-state( 软状态/柔性事务)、Eventual Consistency(最终一致性)。是基于CAP定理演化而来,是对CAP中一致性和可用性权衡的结果。核心思想:即使无法做到强一致性,但每个业务根据自身的特点,采用适当的方式来使系统达到最终一致性。

1、基本可用:指分布式系统在出现故障的时候,允许损失部分可用性,保证核心可用。但不等价于不可用。比如:搜索引擎0.5秒返回查询结果,但由于故障,2秒响应查询结果;网页访问过大时,部分用户提供降级服务,等。

2、软状态:软状态是指允许系统存在中间状态,并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。

3、最终一致性:

系统中的所有数据副本经过一定时间后,最终能够达到一致的状态,不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统,通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计,追求强一致性模型。

ACID,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

软状态、最终一致性,对接支付宝项目。

支付宝流程回调:同步回调地址、异步回调地址。

分布式事务解决方案_数据库_03

 

 

8.CPA理论

CAP由Eric Brewer在2000年PODC会议上提出[1][2],是Eric Brewer在Inktomi[3]期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想:

• 数据一致性(consistency):如果系统对一个写操作返回成功,那么之后的读请求都必须读到这个新数据;如果返回失败,那么所有读操作都不能读到这个数据,对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency)[5]

• 服务可用性(availability):所有读写请求在一定时间内得到响应,可终止、不会一直等待

• 分区容错性(partition-tolerance):在网络分区的情况下,被分隔的节点仍能正常对外服务

9.柔性事务与刚性事务

柔性事务满足Base理论(基本可用、最终一致性)、CAP理论。

刚性事务满足ACID理论。

柔性事务分为:

  9.1.二阶段型

  9.2补偿型

  9.3异步确保型

  9.4最大努力通知型

10.LCN分布式事务原理

LCN并不生产事务,LCN只是本地事务的协调工。

事务协调者、本地服务(订单服务(发起方)、库存服务(参与方))。

发起方:调用其他服务接口。

参与方:被别人调用的接口。

 执行流程:

1.LCN客户端(发起方和参与方都必须要注册到事务协调者中) 建立一个长连接。解答:长连接 好处减少宽带传输 弊端比较占内存。
2.订单服务(发起方)调用库存服务接口(参与方)之前会向TxManager事务协调者创建一个事务的分组id。
3.订单服务(发起方)调用库存服务接口(参与方)的时候,会在请求头中存放该事务的分组id,给库存服务。
4.如果库存服务获取到请求头中有对应的事务分组id,库存服务业务逻辑代码执行完毕的,会采用假关闭,不会提交该事务。

5.参与方在什么时候提交事务?
答案:肯定在发起方 执行成功情况下。
订单服务(发起方)调用库存服务接口(参与方)之后,如果订单服务(发起方)执行没有问题的情况下。
订单服务(发起方)使用对应的事务分组id,通知给TxManager事务协调者,让后TxManager事务协调者在根据该事务分组id,通知给所有的参与方提交事务。

 

分布式事务解决方案_数据_04

集成LCN分布式事务注意事项

版本集成问题: 目前LCN版本已经升级为4.0了,但是官方没有SpringCloud2.0的demo案例。因为LCN本身是开源的,网上有大牛对LCN框架源码做修改,可以支持SpringCloud2.0版本。 使用LCN官方提供的@TxTransaction注解解决分布式事务难题,isStart参数是否LCN事务发起方 true 是:是发起方 false 否:是参与方。

 

LCN 官网:​​http://www.txlcn.org/zh-cn/​

github地址:​​https://github.com/codingapi/tx-lcn​

博客内容来源:​​http://www.mayikt.com/​