面试被问分布式事务(2PC、3PC、TCC),这样解释没毛病!
絮絮叨叨
还记得刚入行开始写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工程师必备的知识点。
长按订阅更多精彩▼如有收获,点个在看,诚挚感谢
面试被问分布式事务(2PC、3PC、TCC),这样解释没毛病!相关推荐
- 分布式事务2PC和TCC有啥不同
一. 什么是2PC 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase).提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提交阶段. ...
- 分布式事务2PC、3PC模型
工作中使用最多的是本地事务,但是在对单一项目拆分为 SOA.微服务之后,就会牵扯出分布式事务场景 文章以分布式事务为主线展开说明,并且针对 2PC.3PC 算法进行详细的讲解,最后通过一个 Demo ...
- 分布式事务专题(四):分布式事务解决方案之TCC
目录: 基础概念 分布式事务理论 分布式事务解决方案之2pc 分布式事务解决方案之TCC(本章) 分布式事务解决方案之可靠消息最终一致性 分布式事务解决方案之最大努力通知 分布式事务综合案例分析 4. ...
- 【分布式事务】内容较多CAP/BASE/2PC/3PC/TCC/Sega等等等等~,一次性捋清楚
分布式事务 概述 什么是分布式事务 分布式事务就是指事务的资源分别位于分布式系统的不同节点之上的事务 分布式事务产生的原因 数据库分库分表 当业务数据量达到单库单表的极限时,就需要考虑分库分表,跨多个 ...
- 分布式事务:XA,2PC,3PC,TCC,SEATA(AT)
一.分布式事务产生原因 1.原本的数据是单库单表存储,随着业务的不断扩大数据量不断增多,单库性能支撑不了数据的更新与访问.为了解决数据库上的瓶颈,将数据库进行水平拆分,原来一个库里的事务操作,现在变成 ...
- 分布式事务2PC、3PC、TCC、RocketMQ事务消息方案详解与对比(详细图解)
这篇文章将介绍分布式事务中的多种实现方案,及各种分布式事务方案的实现原理.事务执行过程.优缺点,读完这篇文章相信你会对2PC.3PC.TCC.MQ事务消息有个详细的了解 分布式事务的处理方法有哪些? ...
- .Net Core with 微服务 - 分布式事务 - 2PC、3PC
最近比较忙,好久没更新了.这次我们来聊一聊分布式事务. 在微服务体系下,我们的应用被分割成多个服务,每个服务都配置一个数据库.如果我们的服务划分的不够完美,那么为了完成业务会出现非常多的跨库事务.即使 ...
- 有关2pc, 3pc,Tcc 的理解
对于分布式事务的概念,可能还会有很多同学不理解或者理解得不是很深刻的地方,在这篇文章中,作者打算重点给大家先介绍下分布式事务相关的基本概念,诸如2PC.3PC.TCC之类的基本问题. 1. 二阶段提交 ...
- 分布式事务管理原理 TCC和LCN 分布式详解
最近笔者在面试过程中发现,分布式的微服务开发越来越广泛了,越来越多的企业在面试时都需要有微服务的经验,那么在谈到微服务的过程中,很多的面试官都会问到一个问题:有没有接触过分布式事务管理?怎么实现分布式 ...
最新文章
- vector int string 化
- tensorflow 入门
- java模拟银行存取_JAVA基础案例 模拟银行存取款业务
- 给初学编程的人的干货
- 共享内存 传一个类指针_共享内存介绍:Shared Memory
- 预处理命令[#define]说明
- mysql查看当前连接数
- 弹出并点击弹框关闭 自定义toast_关于别名配置使用弹框交互应用的思考
- 把字符串按照某几个字符切割成数组
- 计算机语言中字体的设置,font-style字体设置详解
- 项目方说性能达到百万TPS,如何测试它的可信度?
- three.js 后期处理,物体高亮
- 判断Windows服务是否启动
- 安装apache重启的时候,报错端口被占用,错误1
- 使用 URPF 来阻止IP地址欺骗( IP Address Spoofing)
- mes系统服务器架构,MES系统三大层结构是什么
- OpenAI公开Dota 2论文:胜率99.4%,「手术」工具连续迁移训练
- 私有云的优缺点_私有云的优缺点是什么?与公有云的区别
- 爬取唯美女生网站上所有小姐姐的照片
- Altium Designer初学者入门——stm32最小系统的PCB图(接上一篇原理图绘制)
热门文章
- java point_java中point是什么意思
- 关于学习Python的一点学习总结(15)
- 服务器维护简单的备份方案,服务器备份方案计划.doc
- python格式化字符串_Python的3种字符串格式化方法,哪种你最喜欢?
- 0x32.数学知识 - 约数
- html5 颜色弹窗 位置,HTML5之placeholder属性以及如何更改placeholder属性中文字颜色大小位置...
- 新人python2和python3的区别_未明学院:Python2与Python3的主要区别
- python刷题一亩三分地_手把手教你用python抓网页数据【一亩三分地论坛数据科学版】...
- 【Dijkstra算法】未优化版+优先队列优化版
- 关于libStagefright系列漏洞分析