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

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

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

那么在分布式事务中，如何保障事务的一致性呢？解决办法是基于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。

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