【分布式事务】X/OpenDTP事务模型、CAP/Base理论

在看分布式事务之前，我们必须先要清楚的知道事务是什么。事务就是把很多事情当做一件事情来处理，要么一起失败要么一起成功。特别注意一，事务的概念是对数据库而言，比如Spring的@Transactional 本质上就是封装了对数据库事务的一系列操作。关于事务更详细的内容请参考 【MySQL】事务与锁（一）：详解数据库事务及并发时可能出现的问题…

1.分布式事务是什么

在分布式场景下，所涉及到的事务操作不再是单机，而是跨进程

实际上分布式事务问题就是分布式下数据一致性问题，这里的一致性简单一点理解就是所有节点的数据操作/变更一起成功一起失败。

在分布式系统中，每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功还是失败，但却无法直接获取到其他分布式节点的操作结果。那么如何解决这个一致性问题呢？

1. 方案一：让各个节点间通信，各个节点自己协调。

   问题：实现起来复杂，通信频繁，而且对于事务成功失败的考量不属于任何一个服务应该提供的功能

2. 方案二：选取一个第三方组件，作为协调者

   • 整体上看，负责管理全局事务的提交和回滚
   • 实际上，负责记录事务参与者本地事务操作的提交和回滚

实际上述的这种方案就是 X/OpenDTP事务模型的基本雏形。

2.X/OpenDTP事务模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open这个组织定义的一套分布式事务的标准，也就是定义了规范和API接口，由各个厂商进行具体的实现。 这个标准提出了使用二阶段提交(2PC – Two-Phase-Commit)来保证分布式事务的完整性。后来J2EE也遵循了X/OpenDTP规范，设计并实现了java里的分布式事务编程接口规范-JTA。

2.1 三个角色

在X/OpenDTP事务模型中，定义了三个角色：

当一个事务涉及多个分布式节点时，为了保证事务处理的ACID特性，就需要引入一个调度者（TM）来统一调度跨节点的执行逻辑，这些被调度的节点被称为（AP）。TM调度这些AP，并最终决定这些的AP处理后，事务是否进行提交或者回滚，而事务操作最终落实的地方就是RM。

• AP: application, 应用程序，也就是业务层。哪些操作属于一个事务，就是AP定义的。比如上图的用户服务。
• RM： Resource Manager，资源管理器。一般是数据库，也可以是其他资源管理器，比如消息队列， 文件系统。比如上图的db。
• TM： Transaction Manager ，事务管理器、事务协调者，负责接收来自用户程序（AP）发起的XA事务 指令，并调度和协调参与事务的所有RM（数据库），确保事务正确完成。

XA 是X/Open DTP定义的资源管理器和事务管理器之间的接口规范，TM用它来通知和协调相关RM事务的开始、结束、提交或回滚。目前Oracle、Mysql、DB2都提供了对XA的支持； XA接口是双向的系统接口，在事务管理器(TM）以及多个资源管理器之间形成通信的桥梁（XA不能自动提交）

2.2 关于2PC协议

在X/OpenDTP事务模型中用到了2PC，即二阶段提交(2PC – Two-Phase-Commit)。2PC是一个强一致性协议。因为整个事务在TM处理下分为两个阶段提交，所以叫2PC。

阶段一：提交事务请求（投票）

1. 事务询问：TM向所有的参与者发送事务内容，询问能否执行事务提交操作，并开始等待各参与者的响应
   
2. 执行事务：各个参与者节点执行事务操作，并将Undo和Redo信息记录到事务日志中

   关于Undo、Redo日志可以参考 【MySQL】运行原理（四）：重做日志（redo log），回滚日志（undo log），二进制日志（binlog）…

3. 反馈执行结果：如果参与者事务执行成功就返回yes，失败就返回no；向调度者返回结果就类似一个投票过程

阶段二：执行事务提交。根据AP的投票结果（执行结果）最终决定：执行事务 或 回滚事务

存在的问题： 因为2pc是强一致性协议，所以如果第一阶段其中一个RM在写入日志时宕机，或返回后TM网络出现故障，那么第二阶段就会无法进行，RM会一直阻塞，全局事务就卡死在这里了。

• 降低一致性要求，引入过半提交机制；比如zk在第一阶段只要半数节点完成，就进入第二次提交
• 引入timeout超时机制；比如3pc针对此问题进行了改造引入了timeout机制

3.分布式下的目标

3.1 CAP理论

CAP的含义：

• C：Consistency 一致性，同一数据的多个副本是否实时相同。
• A：Availability 可用性，一定时间内如果系统返回一个明确的结果，则称为该系统可用。
• P：Partition tolerance 分区容错性，将同一服务分布在多个系统中，从而保证某一个系统宕机， 仍然有其他系统提供相同的服务。

对于一个业务系统来说，可用性和分区容错性是必须要满足的两个条件，并且这两者是相辅相成的。业务系统之所以使用分布式系统，主要原因有两个：

• 提升整体性能：当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统，使用多个节点提供相同的功能，从而整体上提升系统的性能。
• 实现分区容错性：单一节点或多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。

这说明分区容错性是分布式系统的根本，如果分区容错性不能满足，那使用分布式系统将失去意义。

此外，可用性对业务系统也尤为重要。在大谈用户体验的今天，如果业务系统时常出现“系统异常”、响应时间过长等情况，这使得用户对系统的好感度大打折扣，在互联网行业竞争激烈的今天，相同领域的竞争者不甚枚举，系统的间歇性不可用会立马导致用户流向竞争对手。因此，我们只能通过牺牲一致性来换取系统的可用性和分区容错。

3.2 Base理论

CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件，即CP或AP。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性（AP)。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性

• BA：Basic Available 基本可用，整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。

  “基本可用”和“高可用”的区别是： “一定时间” 可以适当延长 ，比如当举行大促时，响应时间可以适当延长，而给部分用户返回一个降级页面 从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。

• S：Soft State 柔性状态，同一数据的不同副本的状态，可以不需要实时一致。

• E：Eventual Consisstency 最终一致性，同一数据的不同副本的状态，可以不需要实时一致，但 一定要保证经过一定时间后仍然是一致的。