金九银十跳槽季,恶补分布式事务


随着微服务架构在各个企业的渗透,大家都在纷纷的将技术架构转型,从单体式应用变成微服务架构式,从单机部署变分布式部署,我们的应用也变成了分布式应用。在分布式应用中,一切就变得复杂了,如何保障数据的一致性变为最重要的问题。在金九银十的跳槽季中,分布式事务也成为面试中的必考题,因此今天给大家恶补一波分布式事务知识,祝大家可以找到一个满意的工作。

在单体式应用中,因为所有的事务(即某个动作的全流程,比如购物包含付款、下订单、减库存三个操作)都在一个环境里完成,自然可以保障操作的原子性(事务要么全部成功,要么全部失败)、一致性(事务执行前后,数据从一个状态到另一个状态必须是一致的)、隔离性(多个并发事务相互隔离,互不干扰)、持久性(事务完成后,对于数据库的更改是永久保存的,不能回滚)。而在微服务架构的分布式应用中,事务变成了分布式事务(即事务的参与者、支持事务的服务器、资源服务器、事务服务器分别位于不同的分布式系统的不同节点上),一个操作拆分成了多个服务完成,一个服务又在多台机器上完成。

那么在分布式事务中,如何保障事务的一致性呢?解决办法是基于XA协议进行扩展的2PC两阶段提交、3PC三阶段提交、TCC试验确认取消方案。那么XA协议是什么呢?它是一个基于数据库的分布式事务协议,包含事务管理器、本地资源管理器,事务管理器作为全局的调度者,对本地资源管理器统一提交或回滚。

我们先来看看2PC(2phasecommit)两阶段提交,它包含两个阶段的提交,第一阶段是准备阶段,事务管理器(即协调者)询问资源管理器(即参与者)“老铁,准备好了没有啊?可以进行相关操作了吗?”,资源管理器根据自己的情况回答,如果准备好了就会反馈”老板,我这里都准备好了,可以安排对应的工作了“。第二阶段是执行阶段,事务管理器给资源管理器提交一个用户请求,比如创建订单,资源管理器就会进行订单的创建,在创建完成之后,把执行结果返回给事务管理器。如果事务管理器收到某一个资源管理器的失败消息,则直接给所有的资源管理器发送回滚小心,释放事务处理过程中被占用的资源。

 

在这里,你可能觉得2PC已经很完美了,因为每个事务操作它都先询问再操作,有异常就回滚,在分布式系统中完完全全的保障了数据的一致性。其实不然,它也存在着很多问题,比如如果在第二阶段,事务管理器向资源管理器发送提交命令后,出现网络异常请求,只有部分资源管理器收到消息并执行了命令,其它没有收到提交命令的资源协调器就没有办法执行事务,从而导致了整个分布式系统的数据不一致。比如如果事务管理器出现了问题,资源管理器都还处在等待命令的情况,就没有办法完成事务的操作。

道高一尺,魔高一丈,我们有了3PC(3PhaseCommit)三阶段提交,可以把它认为是2PC的升级版。所谓3PC它包含三个阶段cancommit、precommit、docommit。相比两阶段提交,它多了一个precommit准备阶段,确保在最后提交阶段之前,各个参与者资源管理器的状态都一致。并且还增加了超时机制,如果协调者事务管理器出现了问题,参与者资源管理器不会一直等待,而是会执行命令。

 

在3PC中,第一阶段cancommit,协调者会给所有的参与者发送命令,询问他们是否可以干活?各个参与者根据自己的情况进行应答,在第一阶段确认了所有参与者都可以干活后。第二阶段precommit,协调者给所有的参与者发送precommit命令,询问是否可以先做些准备工作,参与者收到命令后,会根据自己的情况判断是否执行操作,如果可以则会返回Yes,在协调者收到所有参与者的Yes命令后。第三阶段docommit,所有的参与者执行事务操作,该加库存的加库存、下订单的下订单,完成任务后返回协调者“任务执行完毕”。

TCC(try-confirm-cancel)是补偿业务,可以把它理解为在业务层面对事务一致性的保障。2PC、3PC更多是在数据库层面去保障各个节点的数据一致性。在TCC中,针对每一个操作都需要确认和补偿,当用户请求过来时,通过分布式事务协调器进行事务的启动,在try阶段时是通过try操作去扣除服务的预留资源;然后通过分布式事务协调器去提交事务,在confirm阶段是确认执行业务操作后,在预留的资源基础上进行购买请求;在cancel阶段是处理某个服务的资源尚未预留成功时,取消所有资源的预留请求。

 

TCC方案倒是很好的保障了数据一致性,但是它也存在一些问题,比如对业务有入侵,我们看到每个服务的操作都包含try、confirm、cancel。

金九银十的跳槽季,正是寻找下一份工作的好时机。而在各大厂的面试中,分布式事务都是常考题,通过本文的介绍,希望小编能助力大家在金九银十的跳槽季找到一个好工作~

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页