分布式事务(一)：分布式事务理论基础
1、概念
1.1、事务特性
事务有四大特性ACID，分别代表原子性、一致性、隔离性、持久性。
A（Atomic）：原子性，要么全部执行成功，要么全部不执行，不允许出现部分成功或部分失败的情况；
C（Consistency）：一致性，事务执行前后，一致性约束未被破坏；
I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题。
D（Durability）：持久性，事务完成后，数据会被持久化到数据库。
1.2、事务
1.2.1、本地事务
在大多数单体架构中，应用程序利用数据库本身的事务特性，通过关系型数据库控制事务，这种事务称为数据库事务。由于数据库往往与应用程序在同一服务器，应用依赖数据库来控制事务，这种基于关系型数据库的事务也被称为本地事务。
1.2.2、分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务要保证操作的原子性、不同数据库的数据一致性。
2、分布式事务理论
2.1、CAP理论
2.1.1、一致性（C）
所有节点在同一时间的数据完全一致
2.1.2、可用性（A）
在集群中部分节点故障后，集群整体还能响应客户端的请求。
2.1.3、分区容错性（P）
分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
在分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
2.2、Base理论
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是基于CAP定理逐步演化而来的，是对CAP中一致性和可用性权衡的结果。BASE理论的核心是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
2.2.1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—-注意，这绝不等价于系统不可用。如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
2.2.2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
2.2.3、最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
3、两阶段提交
两阶段提交保证分布式事务原子性，保证数据的强一致性。所有节点要么全部成功要么全部失败。两阶段提交协议协调所有分布式原子事务参与者，并决定提交或取消(回滚)的分布式算法。
两阶段分别是：准备阶段（Prepare Phase） 、提交阶段（Commit Phase）。
3.1、两阶段提交涉及角色
在两阶段提交协议中，系统一般包含两类角色：
协调者（Coordinator），通常一个系统中只有一个；
参与者（Participant），一般包含多个，在数据存储系统中可以理解为数据副本的个数。
3.2、两阶段提交流程
3.2.1、准备阶段
在准备阶段，协调者将通知事务参与者准备提交或取消事务，写本地的redo和undo日志，但不提交，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
协调者协议流程如下：
写本地日志“BEGIN_COMMIT”，并进入WAIT状态；
向所有参与者发送“VOTE_REQUEST”消息；
等待并接收参与者发送的对“VOTE_REQUEST”的响应。参与者响应“VOTE_ABORT”或“VOTE_COMMIT”消息给协调者。
3.2.2、提交阶段
在提交阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
协调者协议流程如下：
若收到任何一个参与者发送的“VOTE_ABORT”消息；
写本地“GLOBAL_ABORT”日志，进入ABORT状态；
向所有的参与者发送“GLOBAL_ABORT”消息；
若收到所有参与者发送的“VOTE_COMMIT”消息；
写本地“GLOBAL_COMMIT”日志，进入COMMIT状态；
向所有的参与者发送“GLOBAL_COMMIT”消息；
等待并接收参与者发送的对“GLOBAL_ABORT”消息或“GLOBAL_COMMIT”消息的确认响应消息，一旦收到所有参与者的确认消息，写本地“END_TRANSACTION”日志流程结束。
