面试被问分布式事务(2PC、3PC、TCC),这样解释没毛病!
整理了一些Java方面的架构、面试资料(微服务、集群、分布式、中间件等),有需要的小伙伴可以关注公众号【程序员内点事】,无套路自行领取
更多优选
- 一口气说出 9种 分布式ID生成方式,面试官有点懵了
- 面试总被问分库分表怎么办?你可以这样怼他
- 技术部突然宣布:JAVA开发人员全部要会接口自动化测试框架
-
絮絮叨叨
还记得刚入行开始写Java时,接触的第一个项目是国家电网的一个业务系统,这个系统据说投资了5亿人民币进行研发,鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh(Struts+Spring+Hibernate)框架,典型的三层架构(controller - > service -> dao)简单又粗暴,所有人写的代码都放在一个大工程里,项目文件大小达到几百M,解决代码冲突是当时最大的工作量。
然而戏剧性的是,交测当天五人同时上线,项目崩 崩 崩溃了。。。 哎!你永远想象不到甲方愤怒的样子,项目组每个人的祖宗都被问候到了。
说了一些没用的,脑子里总想起这个事,不说不痛快,大家姑且就当笑话听吧,下边我们进入正题
引言
前两天有个学弟公众号留言,说让讲讲分布式事务,面试就挂在这个问题上。时下随着微服务架构体系的流行,面试的题目也都慢慢开始升级,不再是早些年单纯的问点SSH框架知识、数据结构了。高并发
、高可用
、分布式服务治理
、分布式文件系统
、分布式xxx
,反正和分布式沾边的都会问点, 项目实际用不用不要紧,关键你得了解,是不是总有一种学不动了的感觉?
什么是分布式事务?
我们看看百度上对于分布式事务的定义:分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
额~ 看了反而更懵逼了,简单的画个图好让大家理解一下,拿下单减库存来说举例:当系统的业务量很小时,“一站式
”的系统完全可以满足现有业务需求,所有的业务都共用一个数据库,整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。
此时所有操作都在一个事务里,要么全部提交,要么全部回滚 。
但随着业务量不断增长,“一站式
”系统渐渐扛不住巨大的流量,就需要对数据库进行分库分表,将业务服务化拆分(SOA
),就会分离出了订单中心、用户中心、库存中心。而这样就造成业务间相互隔离,每个业务都维护着自己的数据库,数据的交换只能进行RPC调用。
用户再下单时,创建订单和扣减库存,需要同时对订单DB和库存DB进行操作。两步操作必须同时成功,否则就会造成业务混乱,可此时我们只能保证自己服务的数据一致性,无法保证调用其他服务的操作是否成功,所以为了保证整个下单流程的数据一致性,就需要分布式事务介入。
在说分布式事务之前,先回忆一下事务的基本概念:事务是一个程序执行单元,里面的所有操作要么全部执行成功,要么全部执行失败。
一个事务有四个基本特性,也就是我们常说的(ACID
)。
Atomicity
(原子性) :事务是一个不可分割的整体,事务内所有操作要么全做成功,要么全失败。
Consistency
(一致性) :务执行前后,数据从一个状态到另一个状态必须是一致的(A向B转账,不能出现A扣了钱,B却没收到)。
Isolation
(隔离性): 多个并发事务之间相互隔离,不能互相干扰。
Durablity
(持久性) :事务完成后,对数据库的更改是永久保存的,不能回滚。
上面这些知识点都是反反复复念叨的概念,面试必背的东西。
分布式事务解决方案
有困难就一定会有解决问题的办法,什么都难不倒聪明的程序员。
XA协议
是一个基于数据库的分布式事务协议,其分为两部分:事务管理器
和本地资源管理器
。事务管理器
作为一个全局的调度者,负责对各个本地资源管理器统一号令提交
或者回滚
。二阶提交协议(2PC
)和三阶提交协议(3PC
)就是根据此协议衍生出来而来。如今Oracle
、Mysql
等数据库均已实现了XA接口
。
1、两段提交(2PC)
两段提交
顾名思义就是要进行两个阶段的提交:第一阶段,准备阶段(投票阶段) ; 第二阶段,提交阶段(执行阶段)。
上边图片源自网络,如有侵权联系删除
下面还拿下单扣库存举例子,简单描述一下两段提交(2PC)的原理:
之前说过业务服务化(SOA
)以后,一个下单流程就会用到多个服务,各个服务都无法保证调用的其他服务的成功与否,这个时候就需要一个全局的角色(协调者
)对各个服务(参与者
)进行协调。
一个下单请求过来通过协调者
,给每一个参与者
发送Prepare
消息,执行本地数据脚本但不提交事务。
如果协调者
收到了参与者
的失败消息或者超时,直接给每个参与者
发送回滚(Rollback)
消息;否则,发送提交(Commit)
消息;参与者
根据协调者
的指令执行提交或者回滚操作,释放所有事务处理过程中被占用的资源,显然2PC
做到了所有操作要么全部成功、要么全部失败。
两段提交(2PC)的缺点
二阶段提交看似能够提供原子性的操作,但它存在着严重的缺陷
网络抖动导致的数据不一致: 第二阶段中
协调者
向参与者
发送commit
命令之后,一旦此时发生网络抖动,导致一部分参与者
接收到了commit
请求并执行,可其他未接到commit
请求的参与者
无法执行事务提交。进而导致整个分布式系统出现了数据不一致。超时导致的同步阻塞问题:
2PC
中的所有的参与者节点都为事务阻塞型
,当某一个参与者
节点出现通信超时,其余参与者
都会被动阻塞占用资源不能释放。单点故障的风险: 由于严重的依赖
协调者
,一旦协调者
发生故障,而此时参与者
还都处于锁定资源的状态,无法完成事务commit
操作。虽然协调者出现故障后,会重新选举一个协调者,可无法解决因前一个协调者
宕机导致的参与者
处于阻塞状态的问题。
2、三段提交(3PC)
三段提交(3PC)是对两段提交(2PC)的一种升级优化,3PC
在2PC
的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前,各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制,当参与者
各种原因未收到协调者
的commit请求后,会对本地事务进行commit,不会一直阻塞等待,解决了2PC
的单点故障问题,但3PC
还是没能从根本上解决数据一致性的问题。
上边图片源自网络,如有侵权联系删除
3PC 的三个阶段分别是CanCommit
、PreCommit
、DoCommit
CanCommit:协调者向所有参与者发送CanCommit命令,询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。
PreCommit:协调者
向所有参与者
发送PreCommit
命令,询问是否可以进行事务的预提交操作,参与者接收到PreCommit请求后,如参与者成功的执行了事务操作,则返回Yes
响应,进入最终commit阶段。一旦参与者中有向协调者发送了No
响应,或因网络造成超时,协调者没有接到参与者的响应,协调者向所有参与者发送abort
请求,参与者接受abort命令执行事务的中断。
DoCommit: 在前两个阶段中所有参与者的响应反馈均是YES
后,协调者向参与者发送DoCommit
命令正式提交事务,如协调者没有接收到参与者发送的ACK响应,会向所有参与者发送abort
请求命令,执行事务的中断。
3、补偿事务(TCC)
很多初学者总是被TCC
、2PC
、3PC
这几个概念搞混淆,傻傻分不清,实际上 TCC
与 2PC
、3PC
一样,都只是实现分布式事务的一种方案而已。
TCC
(Try-Confirm-Cancel)又被称补偿事务
,TCC
与2PC
的思想很相似,事务处理流程也很相似,但2PC
是应用于在DB层面,TCC则可以理解为在应用层面的2PC
,是需要我们编写业务逻辑来实现。
TCC
它的核心思想是:"针对每个操作都要注册一个与其对应的确认(Try)和补偿(Cancel)"。
还拿下单扣库存解释下它的三个操作:
Try阶段:
下单时通过Try操作去扣除库存预留资源。
Confirm阶段:
确认执行业务操作,在只预留的资源基础上,发起购买请求。
Cancel阶段:
只要涉及到的相关业务中,有一个业务方预留资源未成功,则取消所有业务资源的预留请求。
上边图片源自网络,如有侵权联系删除
TCC的缺点:
应用侵入性强:TCC由于基于在业务层面,至使每个操作都需要有
try
、confirm
、cancel
三个接口。开发难度大:代码开发量很大,要保证数据一致性
confirm
和cancel
接口还必须实现幂等性。
总结
很浅显的介绍了一下2PC、3PC、TCC的概念,如有错误还望温柔指正,分布式事务一直都是面试中比较热点的问题,也是进阶高级Java工程师必备的知识点。
整理了一些Java方面的架构、面试资料(微服务、集群、分布式、中间件等),有需要的小伙伴可以关注公众号【程序员内点事】,无套路自行领取
面试被问分布式事务(2PC、3PC、TCC),这样解释没毛病!的更多相关文章
- 分布式事务 --- 2PC 和 3PC
文章部分图片来自参考资料,侵删 概述 上一篇我们讲到CAP 理论,分区容错性,一致性,可用性三者不可能同时存在,而分区容错性又是客观存在的,那么为了保证可用性,我们牺牲了一致性,虽然我们保证不了强一致 ...
- 分布式事务(2)---TCC理论
分布式事务(2)---TCC理论 上篇讲过有关2PC和3PC理论知识,博客:分布式事务(1)---2PC和3PC理论 我的理解:2PC.3PC还有TCC都蛮相似的.3PC大致是把2PC的第一阶段拆分成 ...
- .Net Core with 微服务 - 分布式事务 - 2PC、3PC
最近比较忙,好久没更新了.这次我们来聊一聊分布式事务. 在微服务体系下,我们的应用被分割成多个服务,每个服务都配置一个数据库.如果我们的服务划分的不够完美,那么为了完成业务会出现非常多的跨库事务.即使 ...
- 如何选择分布式事务形态(TCC,SAGA,2PC,补偿,基于消息最终一致性等等)
各种形态的分布式事务 分布式事务有多种主流形态,包括: 基于消息实现的分布式事务 基于补偿实现的分布式事务(gts/fescar自动补偿的形式) 基于TCC实现的分布式事务 基于SAGA实现的分布式事 ...
- 如何选择分布式事务形态(TCC,SAGA,2PC,基于消息最终一致性等等)
各种形态的分布式事务 分布式事务有多种主流形态,包括: 基于消息实现的分布式事务 基于补偿实现的分布式事务 基于TCC实现的分布式事务 基于SAGA实现的分布式事务 基于2PC实现的分布式事务 这些形 ...
- 分布式:2PC,3PC,Paxos,Raft,ISR [转]
本文主要讲述2PC及3PC,以及Paxos以及Raft协议. 两类一致性(操作原子性与副本一致性) 2PC协议用于保证属于多个数据分片上的操作的原子性.这些数据分片可能分布在不同的服务器上,2PC协议 ...
- 分布式事务之:TCC (Try-Confirm-Cancel) 模式
在当前如火如荼的互联网浪潮下,如何应对海量数据.高并发成为大家面临的普遍难题.广大IT公司从以往的集中式网站架构,纷纷转向分布式的网站架构,随之而来的就是进行数据库拆分和应用拆分,如何在跨数据库.跨应 ...
- 分布式事务专题笔记(三)分布式事务解决方案之TCC(三阶段提交)
个人博客网:https://wushaopei.github.io/ (你想要这里多有) 1.什么是TCC事务 TCC是Try.Confifirm.Cancel三个词语的缩写,TCC要求每个分支 ...
- 分布式事务之:TCC几个框架的测试情况记录
国内主要的开源TCC分布式事务框架包括 框架名称 Github地址 star数量 tcc-transaction https://github.com/changmingxie/tcc-tran ...
随机推荐
- 5.redis主从配置
Redis的主从复制 1.什么是主从复制 持久化保证了即使redis服务重启也不会丢失数据,因为redis服务重启后会将硬盘上持久化的数据恢复到内存中,但是当redis服务器的硬盘损坏了可能会导致数据 ...
- 96)PHP,文件上传(2)
(1)那么既然看到文件即使上传成功,但是只是在脚本周期内有效,脚本只要结束(脚本结束其实很快的),文件就会自动消失,那么怎么才能永久存储文件呢: 函数: Move_uploaded_file(上传临时 ...
- 学习python-20191208(2)-Python Flask高级编程开发鱼书_第03章_数据与flask路由
视频06: 定义静态方法的两种方式: 1.在方法上方加上装饰@staticmethod 2.在方法上方加上装饰@classmethod 方法中要加参数cls 如:def search_by_isb ...
- Range Sum Query - Immutable(easy)
1.这道题目与pat中的1046. Shortest Distance (20)相类似: 2.使用一个数组dp[i],记录0到第i个数的和 3.求i到j之间的和时,输出dp[j]-dp[i]+num[ ...
- 吴裕雄--天生自然 python开发学习笔记:一劳永逸解决绘图出现中文乱码问题方法
import numpy as np import matplotlib.pyplot as plt x = np.random.randint(0,20,10) y = np.random.rand ...
- tomcat部署项目方式
三大部署方式1. Context描述文件部署通过独立的Context文件描述清楚项目的访问路径和地址,tomcat在启动的时候会解析这个Context文件,创建一个Context对象. Conte ...
- motionbuilder安装未完成,某些产品无法安装的解决方法
motionbuilder提示安装未完成,某些产品无法安装该怎样解决呢?,一些朋友在win7或者win10系统下安装motionbuilder失败提示motionbuilder安装未完成,某些产品无法 ...
- HTML name、id、class 的区别
转载: 在一个页面中,有许多的控件(元素或标签).为了更方便的操作这些标签,就需要给这些标签标识一个身份牌. 目录 1. name :指定标签的名称. 2. id :指定标签的唯一标识. 3. cla ...
- 2017 ACM-ICPC, Universidad Nacional de Colombia Programming Contest K - Random Numbers (dfs序 线段树+数论)
Tamref love random numbers, but he hates recurrent relations, Tamref thinks that mainstream random g ...
- 原创:CentOS 环境中 Zabbix 3.4 的安装部署实践
IT管理工作中,如果没有对服务器.网络设备.服务.进程.应用等的监控,往往是用户发送问题报告后才知道出了问题.事后救火显得被动,不能从容面对问题. 才有了部署一套网络监控系统的想法,机缘巧合下结识了Z ...