事务ACID、2PC、3PC、2PL

ACID事务
传统的数据库系统依赖于将工作捆绑到具有 ACID 属性的事务中。如此，他们就通过牺牲可用性或者分区容忍性来保证一致性。ACID 是以下单词的缩写：

Atomicity “All or nothing”
Consistency 隐含着两种类型的一致性。单一系统的一致性以及跨系统的一致性。换句话说，如果从一个银行转出100元至另一个银行。不仅一个银行扣除了100，另一个银行也需要加上这100.
Isolation 无论并发级别如何，事务必须产生相同的结果就像一次只有一个事务执行一样（可以是任何一个可能的执行顺序）
Durability 持久性，即使崩溃了，已有数据依然存在
分布式事务和原子提交协议

通常情况下，事务将分布在多个系统上。如果数据库的多个副本必须保持统一, 则可能会出现这种情况。去实现事务我们需要保证分布式事务必须在所有的系统上有效或者在所有的系统上不执行。为了实现原子性，我们需要原子提交协议。

Two Phase Commit (2PC)
最常用的原子提交协议就是 2PC。两阶段提交让协调者更具参与者信息决定是否提交或放弃事务。

Three Phase Commit (3PC)
另一被用于现实生活中的提交协议是三阶段提交。该协议可以减少阻塞量, 并在发生故障时提供更灵活的恢复。尽管在异常失败易发的环境中，3PC 是更好的选择，但是它的复杂性让 2PC 成为了更受欢迎的选择。

3PC中的恢复

如果参与者发现自己处于 Recovery 状态，它假定协调者没有响应。如果大多数参与者处于不确定和可提交的状态, 则可能会选出新的协调员并继续。一旦我们有了新的协调员, 它就会对参与者进行调查, 并采取相应行动:

如果任何参与者已中止, 它将 Abort 发送给所有人 (此操作是强制性的-“All or nothing”)。
如果任何参与者已提交, 它将 COMMIT 发送给所有人
如果至少有一个参与者处于可提交的状态, 并且大多数参与者是可提交的或不确定的, 将 PRECOMMIT 发送给每个参与者, 并继续进行 “标准计划” 提交。
如果没有可提交的参与者, 但超过一半是不确定的, 发送一个 PREABORT 给所有参与者。然后在一半以上的进程处于可中止状态时, 用一个 ABORT 指令跟进此操作。此操作是必需的, 因为中止是唯一的安全操作。
如果以上所有都不为真，则阻塞直到有更多的响应可用。
Two Phase Locking (2PL)
在我们追求高吞吐量时，我们可能需要并行处理拥有共享资源的两个事务。这时就需要处理隔离性的问题。通常我们使用锁对资源进行访问，但是在并发获取锁的过程中极易出现死锁问题。为了解决死锁问题，我们可以让用户按照一定的顺序对资源加锁，因此不可能会出现事务等待获取一个比自己已拥有的资源更靠前顺序的资源，依赖链也就不可能出现环路。

以上正是两阶段锁的基础。在第一阶段，一个事务严格按照顺序获取所有的锁资源。然后使用资源。在最后的阶段，事务收缩和释放锁。由此就可以防止死锁。

本文主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下:

2PL,两阶段加锁协议:主要用于单机事务中的一致性与隔离性。
2PC,两阶段提交协议:主要用于分布式事务。
MySql本身针对性能，还有一个MVCC(多版本控制)控制,本文不考虑此种技术，仅仅考虑MySql本身的加锁协议。

什么时候会加锁

在对记录更新操作或者(select for update、lock in share model)时，会对记录加锁(有共享锁、排它锁、意向锁、gap锁、nextkey锁等等),本文为了简单考虑，不考虑锁的种类。

什么是两阶段加锁

在一个事务里面，分为加锁(lock)阶段和解锁(unlock)阶段,也即所有的lock操作都在unlock操作之前

为什么需要两阶段加锁

引入2PL是为了保证事务的隔离性，即多个事务在并发的情况下等同于串行的执行。 在数学上证明了如下的封锁定理:

如果事务是良构的且是两阶段的，那么任何一个合法的调度都是隔离的。

具体的数学推到过程可以参照«事务处理:概念与技术»这本书的7.5.8.2节.

此书乃是关于数据库事务的圣经，无需解释(中文翻译虽然晦涩，也能坚持读下去,强烈推荐)

工程实践中的两阶段加锁-S2PL

在实际情况下，SQL是千变万化、条数不定的,数据库很难在事务中判定什么是加锁阶段，什么是解锁阶段。于是引入了S2PL(Strict-2PL),即:

在事务中只有提交(commit)或者回滚(rollback)时才是解锁阶段，其余时间为加锁阶段。

如下图所示:

这样的话，在实际的数据库中就很容易实现了。

两阶段加锁对性能的影响

上面很好的解释了两阶段加锁，现在我们分析下其对性能的影响。考虑下面两种不同的扣减库存的方案:

由于在同一个事务之内，这几条对数据库的操作应该是等价的。但在两阶段加锁下的性能确是有比较大的差距。两者方案的时序如下图所示:

由于库存往往是最重要的热点，是整个系统的瓶颈。那么如果采用第二种方案的话,tps应该理论上能够提升3rt/rt=3倍。这还仅仅是业务就只有三条SQL的情况下，多一条sql就多一次rt,就多一倍的时间。

值得注意的是：

在更新到数据库的那个时间点才算锁成功，提交到数据库的时候才算解锁成功，这两个round_trip的前半段是不会计算在内的。

当前只考虑网络时延，不考虑数据库和应用本身的时间消耗。

依据S2PL的性能优化

从上面的例子中,可以看出，需要把最热点的记录，放到事务***，这样可以显著的提高吞吐量。更进一步:越热点记录离事务的终点越近(无论是commit还是rollback)

避免死锁

这也是任何SQL加锁不可避免的。上文提到了按照记录Key的热度在事务中倒序排列。 那么写代码的时候任何可能并发的SQL都必须按照这种顺序来处理，不然会造成死锁。

select for update和update where谓词计算

我们可以直接将一些简单的判断逻辑写到update的谓词里面，以减少加锁时间

由于update在执行过程中对符合谓词条件的记录加的是和select for update一致的排它锁(具体的锁类型较为复杂，不在这里描述),所以两者效果一样。

总结

MySql采用两阶段加锁协议实现隔离性和一致性，我们只有深入的去理解这种协议，才能更好的对我们的SQL进行优化，增加系统的吞吐量。

两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写前日志（write-ahead log）并持久性存储，即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节点都可以互相通信。

当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务能够成功完成回复同意提交事务或者回滚事务。

顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

阶段2：提交阶段（commit phase）

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

注意 两阶段提交协议与两阶段锁协议不同，两阶段锁协议为一致性控制协议。

两阶段提交协议最大的劣势是其通过阻塞完成的协议，在节点等待消息的时候处于阻塞状态，节点中其他进程则需要等待阻塞进程释放资源才能使用。如果协调器发生了故障，那么参与者将无法完成事务则一直等待下去。以下情况可能会导致节点发生永久阻塞：

如果参与者发送同意提交消息给协调者，进程将阻塞直至收到协调器的提交或回滚的消息。如果协调器发生永久故障，参与者将一直等待，这里可以采用备份的协调器，所有参与者将回复发给备份协调器，由它承担协调器的功能。

如果协调器发送“请求提交”消息给参与者，它将被阻塞直到所有参与者回复了，如果某个参与者发生永久故障，那么协调器也不会一直阻塞，因为协调器在某一时间内还未收到某参与者的消息，那么它将通知其他参与者回滚事务。

同时两阶段提交协议没有容错机制，一个节点发生故障整个事务都要回滚，代价比较大。

当一个事务要跨越多个分布式节点的时候（比如，淘宝下单流程，下单系统和库存系统可能就是分别部署在不同的分布式节点中），为了保证该事务可以满足ACID，就要引入一个协调者（Cooradinator）。其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。

二阶段提交协议（2PC）
二阶段提交协议主要分为来个阶段：准备阶段和提交阶段。

值得注意的是，二阶段提交协议的第一阶段准备阶段不仅仅是回答YES or NO，还是要执行事务操作的，只是执行完事务操作，并没有进行commit还是roolback。

2PC存在的问题
下面我们来分析下2PC存在的问题。

这里暂且不谈2PC存在的同步阻塞、单点问题、脑裂等问题（上篇文章中有具体介绍），我们只讨论下数据一致性问题。作为一个分布式的一致性协议，我们主要关注他可能带来的一致性问题的。

2PC在执行过程中可能发生协调者或者参与者突然宕机的情况，在不同时期宕机可能有不同的现象。

情况一：协调者挂了，参与者没挂
这种情况其实比较好解决，只要找一个协调者的替代者。当他成为新的协调者的时候，询问所有参与者的最后那条事务的执行情况，他就可以知道是应该做什么样的操作了。所以，这种情况不会导致数据不一致。

情况二：参与者挂了，协调者没挂
这种情况其实也比较好解决。如果协调者挂了。那么之后的事情有两种情况：

第一个是挂了就挂了，没有再恢复。那就挂了呗，反正不会导致数据一致性问题。

第二个是挂了之后又恢复了，这时如果他有未执行完的事务操作，直接取消掉，然后询问协调者目前我应该怎么做，协调者就会比对自己的事务执行记录和该参与者的事务执行记录，告诉他应该怎么做来保持数据的一致性。

情况三：参与者挂了，协调者也挂了
这种情况比较复杂，我们分情况讨论。

协调者和参与者在第一阶段挂了。

由于这时还没有执行commit操作，新选出来的协调者可以询问各个参与者的情况，再决定是进行commit还是roolback。因为还没有commit，所以不会导致数据一致性问题。
第二阶段协调者和参与者挂了，挂了的这个参与者在挂之前并没有接收到协调者的指令，或者接收到指令之后还没来的及做commit或者roolback操作。

这种情况下，当新的协调者被选出来之后，他同样是询问所有的参与者的情况。只要有机器执行了abort（roolback）操作或者第一阶段返回的信息是No的话，那就直接执行roolback操作。如果没有人执行abort操作，但是有机器执行了commit操作，那么就直接执行commit操作。这样，当挂掉的参与者恢复之后，只要按照协调者的指示进行事务的commit还是roolback操作就可以了。因为挂掉的机器并没有做commit或者roolback操作，而没有挂掉的机器们和新的协调者又执行了同样的操作，那么这种情况不会导致数据不一致现象。
第二阶段协调者和参与者挂了，挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了，没有人知道他执行了什么操作。

这种情况下，新的协调者被选出来之后，如果他想负起协调者的责任的话他就只能按照之前那种情况来执行commit或者roolback操作。这样新的协调者和所有没挂掉的参与者就保持了数据的一致性，我们假定他们执行了commit。但是，这个时候，那个挂掉的参与者恢复了怎么办，因为他之前已经执行完了之前的事务，如果他执行的是commit那还好，和其他的机器保持一致了，万一他执行的是roolback操作那？这不就导致数据的不一致性了么？虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！
所以，2PC协议中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

为了解决这个问题，衍生除了3PC。我们接下来看看3PC是如何解决这个问题的。

三阶段提交协议（3PC）
3PC最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。在第一阶段，只是询问所有参与者是否可可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

3PC为什么比2PC好？
直接分析协调者和参与者都挂的情况。

第二阶段协调者和参与者挂了，挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了，没有人知道他执行了什么操作。

这种情况下，当新的协调者被选出来之后，他同样是询问所有的参与者的情况来觉得是commit还是roolback。这看上去和二阶段提交一样啊？他是怎么解决一致性问题的呢？

看上去和二阶段提交的那种数据不一致的情况的现象是一样的，但仔细分析所有参与者的状态的话就会发现其实并不一样。我们假设挂掉的那台参与者执行的操作是commit。那么其他没挂的操作者的状态应该是什么？他们的状态要么是prepare-commit要么是commit。因为3PC的第三阶段一旦有机器执行了commit，那必然第一阶段大家都是同意commit。所以，这时，新选举出来的协调者一旦发现未挂掉的参与者中有人处于commit状态或者是prepare-commit的话，那就执行commit操作。否则就执行rollback操作。这样挂掉的参与者恢复之后就能和其他机器保持数据一致性了。（为了简单的让大家理解，笔者这里简化了新选举出来的协调者执行操作的具体细节，真实情况比我描述的要复杂）

简单概括一下就是，如果挂掉的那台机器已经执行了commit，那么协调者可以从所有未挂掉的参与者的状态中分析出来，并执行commit。如果挂掉的那个参与者执行了rollback，那么协调者和其他的参与者执行的肯定也是rollback操作。

所以，再多引入一个阶段之后，3PC解决了2PC中存在的那种由于协调者和参与者同时挂掉有可能导致的数据一致性问题。

3PC存在的问题
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。

所以，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。