分布式 - 分布式事务面试题
1 分布式事务面试题
现在Java面试,分布式系统、分布式事务几乎是标配。而分布式系统、分布式事务本身比较复杂,大家学起来也非常头疼。
最为常见的面试题:
问题1、分布式事务产生的背景?
问题2、常见的分布式事务解决方案?
1、使用MQ
2、使用LCN
3、使用Seata
4、2PC、3PC
问题3、什么是Seata?
Seata是阿里巴巴退出的一款用来解决分布式事务问题的框架,他经过天猫双十一的考验,很有可能成为解决分布式事务问题的主流框架
问题4、Seata分布式事务框架实现原理?
问题5、SpringBoot如何整合Seata?
问题6、Seata和LCN的区别?
系列问题: 分布式事务相关的概念介绍?
概念 | 说明 |
---|---|
分布式事务 | 横跨多个服务,操作多个数据库;跨库、分库分表、分服务 |
DTP 模型 | DTP模型的5个基本元素:应用程序 AP 资源管理器 RM 事务管理器 TM通信资源管理器 CRM 通信协议 CP |
XA规范 | 定义了RM-TM的交互接口 |
两阶段提交协议 2PC |
![]() |
三阶段提交协议 3PC | 协调者、参与者都引入了超时机制;三阶段 CanCommit、PreCommit(其中一个超时或者执行失败,则TM发起中断)和doCommit 3PC :优点 :引入超时机制,降低了协调者与参与者之间的阻塞范围;缺点:在参与者接收到preCommit之后,如果出现网络分区,那么该参与者节点会继续执行事务的提交,而其他节点会执行中断事务,最终会造成数据的不一致。 |
CAP 定理BASE理论 | CAP : 大规模的分布式系统时会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance )最多只能满足其中的2项 BASE理论 : 基本可用、软状态、最终一致 |
刚性事务、柔性事务 | 刚性事务–强一致性 两阶段提交协议(2PC) 柔性事务–最终一致性 TCC(两阶段型、补偿型)、最大努力通知、可靠消息最终一致 |
TCC(两阶段型、补偿型) | Try阶段: 完成所有业务检查(一致性),预留业务资源(准隔离性)**Confirm阶段:**确认执行业务操作,不做任何业务检查, 只使用Try阶段预留的业务资源。Cancel阶段: 取消Try阶段预留的业务资源。 |
TCC 与 XA | XA是资源层面的分布式事务,强一致性 ,一直会持有资源的锁;TCC是业务层面的分布式事务,最终一致性,不会一直持有资源的锁 TCC :优点:避免了XA两阶段提交占用资源锁时间过长导致的性能低下问题缺点:主业务服务和从业务服务都需要进行改造,从业务方改造成本更 |
最大努力通知型如银行通知、商户通知等 | 最简单的一种柔性事务 1、不可靠消息:业务活动主动方,在完成业务处理之后,向业务活动的被动方发送消息,直到通知N次后不再通知,允许消息丢失(不可靠消息)。 2、定期校对:业务活动的被动方,根据定时策略,向业务活动主动方查询(主动方提供查询接口),恢复丢失的业务消息。 |
可靠消息最终一致 |
RocketMQ的事务消息机制![]() |
2 事务简介
事务(Transaction)是操作数据库中某个数据项的一个程序执行单元(unit)。事务应该具有4个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。
(1)原子性(atomicity):个事务是一个不可分割的工作单位,事务中包括的诸操作要么都做,要么都不做。
事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于有效状态。
如果在事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态。
(3)隔离性(isolation):一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。
比方说:一个人买东西的时候需要记录在账本上,即使老板忘记了那也有据可查。
1.1.2 MySQL的事务实现方案
大多数场景下,我们的应用都只需要操作单一的数据库,这种情况下的事务称之为本地事务(Local Transaction)。本地事务的ACID特性是数据库直接提供支持。
大部分人对 MySQL 都比较熟悉,以MySQL 的InnoDB (InnoDB 是 MySQL 的一个存储引擎)为例,介绍一下单一数据库的事务实现原理。
InnoDB 是通过 日志和锁 来保证的事务的 ACID特性,具体如下:
(2)通过 Redo Log(重做日志)来,保障事务的持久性;
(3)通过 Undo Log (撤销日志)来,保障事务的原子性;
(4)通过 Undo Log (撤销日志)来,保障事务的一致性;
1.1.3 什么是分布式事务?
对于分布式系统而言,需要保证分布式系统中的数据一致性,保证数据在子系统中始终保持一致,避免业务出现问题。分布式系统中对数要么一起成功,要么一起失败,必须是一个整体性的事务。
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说,在分布式系统上一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务节点上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。
任何事务机制在实现时,都应该考虑事务的ACID特性,包括:本地事务、分布式事务。对于分布式事务而言,即使不能都很好的满足,也要考虑支持到什么程度。
1. 跨库事务
跨库事务指的是,一个应用某个功能需要操作多个库,不同的库中存储不同的业务数据。笔者见过一个相对比较复杂的业务,一个业务中同时操作了9个库。下图演示了一个服务同时操作2个库的情况:
2. 分库分表
通常一个库数据量比较大或者预期未来的数据量比较大,都会进行水平拆分,也就是分库分表。如下图,将数据库B拆分成了2个库:
对于分库分表的情况,一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。如,对于sql:insert into user(id,name) values (1,“tianshouzhi”),(2,“wangxiaoxiao”)。这条sql是操作单库的语法,单库情况下,可以保证事务的一致性。
但是由于现在进行了分库分表,开发人员希望将1号记录插入分库1,2号记录插入分库2。所以数据库中间件要将其改写为2条sql,分别插入两个不同的分库,此时要保证两个库要不都成功,要不都失败,因此基本上所有的数据库中间件都面临着分布式事务的问题。
3. 服务化(SOA)
微服务架构是目前一个比较一个比较火的概念。例如上面笔者提到的一个案例,某个应用同时操作了9个库,这样的应用业务逻辑必然非常复杂,对于开发人员是极大的挑战,应该拆分成不同的独立服务,以简化业务逻辑。拆分后,独立服务之间通过RPC框架来进行远程调用,实现彼此的通信。下图演示了一个3个服务之间彼此调用的架构:
Service A完成某个功能需要直接操作数据库,同时需要调用Service B和Service C,而Service B又同时操作了2个数据库,Service C也操作了一个库。需要保证这些跨服务的对多个数据库的操作要不都成功,要不都失败,实际上这可能是最典型的分布式事务场景。
分布式事务实现方案必须要考虑性能的问题,如果为了严格保证ACID特性,导致性能严重下降,那么对于一些要求快速响应的业务,是无法接受的。
3 分布式事务的理论基础
数据库事务ACID 四大特性,无法满足分布式事务的实际需求,这个时候又有一些新的大牛提出一些新的理论。
1.2.1 CAP定理
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的,他指出WEB服务无法同时满足一下3个属性:
一致性(Consistency) : 客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) : 每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) : 即使出现单个组件无法可用,操作依然可以完成
具体地讲在分布式系统中,一个Web应用至多只能同时支持上面的两个属性。因此,设计人员必须在一致性与可用性之间做出选择。
2000年7月Eric Brewer教授仅仅提出来的是一个猜想,2年后,麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论,并且而一个分布式系统最多只能满足CAP中的2项。之后,CAP理论正式成为分布式计算领域的公认定理。
所以,CAP定理在迄今为止的分布式系统中都是适用的!
CAP的一致性、可用性、分区容错性 具体如下:
1. 数据一致性
数据一致性指“all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致,不能存在中间状态。
例如对于电商系统用户下单操作,库存减少、用户资金账户扣减、积分增加等操作必须在用户下单操作完成后必须是一致的。不能出现类似于库存已经减少,而用户资金账户尚未扣减,积分也未增加的情况。如果出现了这种情况,那么就认为是不一致的。
数据一致性分为强一致性、弱一致性、最终一致性。
如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的,那么称之为强一致性。
如果允许存在中间状态,只要求经过一段时间后,数据最终是一致的,则称之为最终一致性。
此外,如果允许存在部分数据不一致,那么就称之为弱一致性。
面试题:什么是数据一致性?现在知道怎么回答了吧!
- 1
- 2
- 3
2. 可用性
可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有限的时间内”是指,对于用户的一个操作请求,系统必须能够在指定的时间内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的。
试想,如果一个下单操作,为了保证分布式事务的一致性,需要10分钟才能处理完,那么用户显然是无法忍受的。“返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果,不论这个结果是成功还是失败。
3. 分区容错性
分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。
CAP理论已经被证明:一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点,我们就需要抛弃一个。
但分区容错性是不能被抛弃的那个,为什么呢?对于一个分布式系统而言,分区容错性是一个最基本的要求。因为既然是一个分布式系统,那么分布式系统中的组件必然需要被部署到不同的节点,否则也就无所谓分布式系统了。而对于分布式系统而言,网络问题又是一个必定会出现的异常情况,因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。
既然分区容错性不能抛弃,那么,只能在一致性、可用性寻找平衡。因此系统架构师往往需要把精力花在如何根据业务特点在C(一致性)和A(可用性)之间做取舍。
而前面我们提到的X/Open XA 两阶段提交协议的分布式事务方案,强调的就是一致性;由于可用性较低,实际应用的并不多。而基于BASE理论的柔性事务,强调的是可用性,目前大行其道,大部分互联网公司采可能会优先采用这种方案。
1.2.2 BASE理论
BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。
指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性。
强调的是所有的数据更新操作,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
4 分布式事务的主要方案
分布式事务的实现主要有以下 5 种方案:
两阶段提交方案XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
分为两个大类:
1. CAP理论的事务方案:
- 两阶段提交方案/XA方案
2. BAS柔性事务方案:
TCC(两阶段型、补偿型)
本地消息表
可靠消息最终一致性(异步确保型)
最大努力通知(非可靠消息、定期校对)
1.3.3 两阶段提交模式(2PC)的XA 方案
第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交.
其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。
如果你要操作别人的服务的库,你必须是通过调用别的服务的接口来实现,绝对不允许交叉访问别人的数据库。
1.3.4 TCC 方案
TCC 方案的全称是:Try、Confirm、Cancel。
l Try 阶段:对各个服务的资源做检测以及对资源进行锁定或者预留。
l Cancel 阶段:如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿动作。补偿动作具体来说,就是对已经执行成功的业务逻辑的回滚操作。
TCC 方案严重依赖回滚和补偿代码,最终的结果是:回滚代码逻辑复杂,业务代码很难维护。所以,TCC 方案的使用场景较少,但是也有使用的场景。
比如说跟钱打交道的,支付、交易相关的场景,大家会用 TCC方案,严格保证分布式事务要么全部成功,要么全部自动回滚,严格保证资金的正确性,保证在资金上不会出现问题。
1.3.5 本地消息表
(1)A 系统在自己本地一个事务里操作同时,插入一条数据到消息表;
(3)B 系统接收到消息之后,在一个事务里,往自己本地消息表里插入一条数据,同时执行其他的业务操作,如果这个消息已经被处理过了,那么此时这个事务会回滚,这样保证不会重复处理消息;
(4)B 系统执行成功之后,就会更新自己本地消息表的状态以及 A 系统消息表的状态;
(5)如果 B 系统处理失败了,那么就不会更新消息表状态,那么此时 A 系统会定时扫描自己的消息表,如果有未处理的消息,会再次发送到 MQ 中去,让 B 再次处理;
(6)这个方案保证了最终一致性,哪怕 B 事务失败了,但是 A 会不断重发消息,直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的,会导致如果是高并发场景咋办呢?咋扩展呢?所以一般确实很少用。
1.3.6 可靠消息最终一致性方案
这个的意思,就是干脆不要用本地的消息表了,直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。
(1)A 系统先发送一个 prepared 消息到 mq,如果这个 prepared 消息发送失败那么就直接取消操作别执行了;
(2)如果这个消息发送成功过了,那么接着执行本地事务,如果成功就告诉 mq 发送确认消息,如果失败就告诉 mq 回滚消息;
(3)如果发送了确认消息,那么此时 B 系统会接收到确认消息,然后执行本地的事务;
1.3.7 最大努力通知方案
(2)这里会有个专门消费 MQ 的最大努力通知服务,这个服务会消费 MQ 然后写入数据库中记录下来,或者是放入个内存队列也可以,接着调用系统 B 的接口;
(3)要是系统 B 执行成功就 ok 了;要是系统 B 执行失败了,那么最大努力通知服务就定时尝试重新调用系统 B,反复 N 次,最后还是不行就放弃。
1.4 面试中如何应答?
TCC用于强一致主要用于核心模块,例如交易/订单等。最终一致方案一般用于边缘模块例如库存,通过mq去通知,保证最终一致性,也可以业务解耦。
(1)对于那些特别严格的场景,用的是 TCC 来保证强一致性;
准备好例子:你找一个严格要求数据绝对不能错的场景(如电商交易交易中的资金),可以回答使用成熟的如中间件如阿里分布式事务seata组件。
阿里开源了分布式事务框架,fescar,seata。seata类似TCC事务,经历过阿里生产环境大量考验的框架。seata支持Dubbo,Spring Cloud。
准备好例子:你找一个严格对数据一致性要求没有那么严格的场景,如电商订单插入之后要调用库存服务更新库存,库存数据没有那么严格,比如少一点点也行,只需要保障最终一致性即可。
现在大量用RocketMQ,作为MQ中间件,
RocketMQ提供了分布式事务支持,已经把可靠消息服务需要实现的功能逻辑已经做好了。
分布式 - 分布式事务面试题相关推荐
- 分布式的事务该怎么做?
分布式八大坑 分布式就是魔鬼啊! 张大胖最近十分感慨,他所在的公司原来有个电商系统,后来随着用户量越来越大,对系统的可用性要求越来越高. CTO要求把系统进行拆分, 从一个单体的应用,拆分成微服务组成 ...
- CSDN开发者周刊 TDengine:专为物联网订制的大数据平台 YugaByte DB:高性能的分布式ACID事务数据库
CSDN开发者周刊: TDengine:专为物联网订制的大数据平台 YugaByte DB:高性能的分布式ACID事务数据库 CSDN开发者周刊:只为传递"有趣/有用"的开发者 ...
- 分布式交易事务_交易基础和分布式交易
当客户在网上商店购买商品时,您希望您的订单能够被快速处理和交付. 作为银行客户,您要确保转账期间钱不会神秘地消失. 在企业应用程序中,经典事务保证了诸如一致性和与其他事务的隔离之类的质量. 分布式事务 ...
- 分布式-分布式常见问题和解决方案
分布式锁 首先我们先来看一个小例子: 假设某商城有一个商品库存剩10个,用户A想要买6个,用户B想要买5个,在理想状态下,用户A先买走了6了,库存减少6个还剩4个,此时用户B应该无法购买5个,给出数量 ...
- 分布式缓存Redis面试题
来源:https://github.com/shishan100/Java-Interview-Advanced 面试题 redis 和 memcached 有什么区别?redis 的线程模型是什么? ...
- 你真的很熟分布式和事务吗?
微吐槽 hello,world. 不想了,我等码农,还是看看怎么来处理分布式系统中的事务这个老大难吧! 本文略长,读者需要有一定耐心,如果你是高级码农或者架构师级别,你可以跳过. 本文注重实战或者实现 ...
- spring整合atomikos实现分布式事务的方法示例_分布式-分布式事务处理
在之前的文章"如何合理的使用动态数据源"中,其实也提到了分布式事务相关的场景如:利用多数据源实现读写分离,但直接使用动态数据源频繁其实是很消耗资源的,而且就是当业务service一 ...
- mybatis+redis实现分布式缓存+缓存面试题
一,mybatis缓存机制 mybatis提供了一级.二级缓存. 一级缓存:线程级别的缓存,也称为本地缓存或sqlSession级别的缓存,一级缓存是默认存在的,同一个会话中,查询两次相同的操作就会从 ...
- 数据库怎么保证(分布式)事务一致性
浅谈事务与一致性问题 原文地址 https://www.jianshu.com/p/f0a1b00a6002 在高并发场景下,分布式储存和处理已经是常用手段.但分布式的结构势必会带来"不一致 ...
最新文章
- VSS admin用户忘记密码的解决方法
- 使用Spring Boot和Logback登录到Redis
- mysql5.7.18压缩包下载_Windows安装MySQL5.7教程
- 阿里HBase高可用8年抗战回忆录
- java比赛用多重for_关于 Java 中 for的多重循环
- python海龟绘图画树_Python:海龟绘图(二)
- linux一句话问答(网络无关篇+网络相关篇+程序开发篇+经典图书)
- ES6个人小手册,走过路过不要错过。。。。。
- 3 Machine-Level Representation 程序的机器级表示
- brew更新的时候不更新某个应用_可以不可以第六集剧情介绍,日剧可以不可以什么时候更新...
- 凸优化第四章凸优化问题 4.3线性规划问题
- MATLAB bp神经网络的雾霾天气下交通标志的识别系统
- 如何用电脑画平面坐标图_如何画坐标图?
- math.h里的数学计算公式介绍
- python中如何保存并使用训练好的模型并调用
- python3.7反编译生成的.exe
- torch.atan2函数详细解答
- 2020计算机数电实验二
- 专业术语-外文首字母组词的原词组
- vue3.x 重复点击路由报错