分布式事务

分布式事务

什么是分布式？

了解分布式之前先看一下单机和集群的概念

单机结构

单机就是所有业务全部写在一个项目中，部署服务到一台服务器上，所有请求业务都由这台服务器去处理，当业务增长到一定程度的时候，服务器的硬件会无法满足业务需求，然后就会想到一个程序不行就部署多个。

集群

1. 集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，部署N个节点，处理业务的能力就提升N倍，这些节点的结合就叫做集群。
2. 负载均衡：协调群里的每个节点均衡的接受业务请求，通俗的讲就是服务A和服务B相同时间段内处理的同类业务请求数量是类似的。

分布式

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
举个例子，假如需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等。

分布式事务

分布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现有很多中，最具有代表性的是oracle系统提出的XA分布式事务协议。

XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现：

在XA协议中包含着两个角色：事务协调者和事务参与者。

第一阶段

在XA分布式事务的第一阶段，作为事务协调者的阶段会首先向所有的参与者节点发送Prepare请求。

在接到Prepare请求之后，每个参与者节点会各自事务相关的数据更新，写入Undo Log 和 Redo Log。如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息。

当事务协调者接收到所有参与者返回消息，整个分布式事务将会进入第二阶段。

第二阶段

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么他将会向所有事务参与者发出commit提交。

接到commit请求之后，十五参与者节点会各自进行本地的事务提交，并释放资源。当本地事务完成提交之后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

失败处理流程

在XA的第一阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

于是在第二阶段，事务协调节点向所有的事务参与者发送Abort请求。接收到Abort请求之后，各个事务参与者节点需要在本地进行事务的回滚操作，回滚操作依照Undo Log来进行。

两段提交不足之处

1. 性能问题

   XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有阶段准备完毕，事务协调者才会通知提交，参与者提交之后释放资源。这样的过程有着非常明显的性能问题。

2. 协调者单点故障问题

   事务协调这是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回国通知，参与者会一直处于中间状态无法完成事务。

3. 丢失消息导致不一致问题

   在第二阶段，如果发生局部网络问题，一部分事务参与者收到提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

解决方案：

1. XA三段提交

   XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。

2. MQ事务

   利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。

3. TCC事务

   TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

推荐文章：漫画：什么是分布式事务？ 分布式事务六种解决方案