6.824：分布式事务---two phase commit

当前把大量的数据拆分到不同的服务器上，这是十分常见的一种情况。

在分布式事务中，需要一种机制来确保在遇到并发和故障的情况下，执行这些事务也可以得到正确的结果。首先从基本的事务来讲。

数据库中对事务的正确性提出了ACID

原子性：分布式事务要么执行完毕，要么不执行

一致性：状态必然是从一致的状态变到另一个一致的状态，这并非是重点。

隔离性：一个事务执行的中间状态不应该被其他事务看到，也就是事务在执行的时候，彼此看不到对方做的修改内容，也就是事务的执行是有顺序的，这是重点。

持久化：当这个事务被提交的时候，表明事务执行完毕，将会给客户端回复事务执行结果，这个修改是持久的，不会因为故障而消失。

我们应该着重于隔离性这个属性，在多个事务的并发执行，这其中的执行顺序是十分复杂的，存在很多种。很多执行顺序都能产生正确的执行结果。那么执行顺序带来结果的正确性就需要定义，有序化serializable是一个流行且有用的定义，只要事务的执行是有序化的，那么就是正确的。

有序化的情况是正确的，这十分好理解，事务有序依次执行，不会收到其他并发的事务的影响，那么执行结果必然是正确的，有序化就是要求结果是这个事务单独执行时所产生的结果。

那么事务只要执行的时候，使用的数据对象始终只有当前事务在使用，也就是没有其他影响事务的事情发生。也就是按照这个定义，只要事务执行的时候使用的数据对象并不重合，那么这些事务就可以并行执行。可以根据此来构建一个数据库系统，使得这个系统内的事务能够真正实现并行执行。

但是当前我们需要考虑的是分片系统，数据分别存储在不同的机器上，也就是在一个事务涉及的数据可能分布在多台机器上，需要在多台机器上并行处理不同的数据。

如何让分布式事务具备ACID特性

分布式数据库，数据是分布在多台服务器上，支持分布式事务。分布式系统中经常碰到的问题就是部分故障，就是有部分服务器发生故障。还有就是分布式事务也需要确保是有序化的，具有原子性的。

并发控制

并发控制是确保事务的执行有序化，能够让那些存在数据竞争的事务之间相互隔离。事务的并发控制可以用锁来实现，锁又分为以下两种锁，悲观锁和乐观锁。

悲观并发锁：使用任何数据前，先获取数据对应的锁，该方案会带来阻塞等待延迟，为了正确性牺牲一定的性能。如果数据冲突经常发生，悲观锁更合适。

乐观并发锁：不担心事务之间的数据竞争问题，将事务的执行结果写入临时区域，在事务执行结束后再检查事务是否执行正确。如果数据冲突很少发生，乐观锁更合适。

此处着重介绍悲观锁-----两阶段锁。

两阶段锁：对任何数据进行操作前，先获取对应的锁，只有事务被提交或终止后，锁才能被释放。

这种经典的锁机制也是会造成死锁的问题，但是死锁问题解决办法也很多，超时机制等都可以用来检测死锁。后续就终止其中一个发生冲突的事务，并回滚恢复事务的修改即可。

原子提交

一个分布式事务的完成涉及到多台服务器上的任务，必须要所有服务器上的任务都完成后，事务才能够提交，其中有部分执行该事务的服务器发生了崩溃，那么就需要进行回滚恢复。事务那么全部执行，要么全部不执行。

原子提交这块，我们需要特别注意的就是分布式系统中会碰到诸多问题，像服务器故障、消息丢失等。

原子提交也可以通过两阶段锁来解决，这个原子提交协议就是通过两阶段锁来实现一个两阶段提交。

事务协调器

对于分布式事务，事务的内容涉及到多台服务器上的工作，需要专门设定一台服务器作为事务协调器，这个事务协调器将负责协调多台服务器实现并发控制和原子提交。

事务协调器上维护了一张lock表，记录每个事务所需要的锁。在事务协调器看来，负责处理事务的其他服务器为参与者。

当事务协调器收到客户端发送来的一个事务，便会给这个事务分配一个id，并获悉这个事务涉及的数据，以及对应这些数据的锁。协调器会给存储了这些数据的参与者服务器发送操作请求。

其余的服务器上自身也会维护一张lock表，表中记录了哪些事务正在占用哪些数据。

流程讲解

客户端向事务协调器发起一个事务，协调器会给涉及到这个事务的所有参与者发送操作请求，为了确保这些参与者能够完成给定的那一部分任务，协调器还会给所有参与者发送prepare消息来询问是否保证完成。

如图所示，TC事务协调器根据事务的内容，需要给参与者A发放get操作，给参与者B发放put操作，后续再向A、B发送prepare消息咨询是否保证完成。如果参与者能够执行这个事务的操作则返回yes；若这个操作对应的锁无法获取，发生了死锁，或者是参与者发送了故障重启忘记了该事务，那么就要返回no。

事务协调器必须要收到全部参与者的回复为yes，才可提交事务并返回事务的执行结果给客户端，并发送commit消息给参与者，使执行结果持久化，并删除该事务相关的日志，并回复ack给事务协调器。否则将会给参与者发送abort消息，回滚事务。

有序化的实现

参与者在接受到来自协调器的操作请求的时候，就需要先申请相关数据的锁，该事务申请的锁的信息也将被记录在参与者本地的lock表中，当事务执行结束后，收到来自协调器的commit消息后，即可提交事务，持久化结果，并释放锁。如果，在申请相关数据的锁的时候，发现对应的锁正被其他事务所占用，则需要阻塞等待其他事务释放锁。这样就避免了不同事务对相同数据的竞争使用，确保有序执行。

原子性的实现

上述的设计中，在服务器集群都正常运行的情况下，不碰到服务器崩溃的情况下，能够确保事务被每个参与者保证完成后，才进行提交，这能确保事务的原子性，这也就是两阶段提交机制。

但是分布式系统需要考虑服务器的意外崩溃重启，我们需要考虑在不同时间点崩溃重启的解决办法。

根据两阶段锁，我们在考虑服务器崩溃时，可以将崩溃时间划分为以下几种情况：

参与者的崩溃重启

1、在参与者回复prepare消息之前发生了崩溃，那么参与者就不会对协调器回复yes，那么这个事务就必然无法提交，注定被回滚恢复，因为协调器需要全部参与者回复yes才能提交，否则就abort回滚这个事务。

2、在参与者回复prepare消息yes后发生了崩溃，此时参与者重启后内存中信息将没有该事务本地执行yes的记录了，然而协调器已经收到yes的回复，后续就会提交并要求参与者也进行本地提交并持久化。因此参与者在发送yes消息前，必须要将事务的信息持久化到磁盘上，然后再发送yes给协调器，这样即使崩溃重启，读取磁盘上的日志也可以得知该事务的情况，并完成后续的事务提交，持久化。

3、在参与者收到commit消息后崩溃，参与者收到commit消息后，已经将事务所做的修改持久化，那么参与者崩溃重启将不会有任何影响，事务也已经结束了，该事务相关的日志也会被删除。

参与者收到commit后，结束了事务，删除了事务相关的日志，又重复收到该事务的commit请求，怎么办？

这种情况，参与者发现本地没有该事务的数据，但是该事务已经到了commit阶段，这表明该事务在本地必然已经提交持久化过了，因此仅需回复ack即可。

协调器的崩溃重启

1、在协调器发送commit之前崩溃，该事务并没有提交，该事务后续将会被abort回滚。协调器崩溃重启后，忘记该事务，当参与者询问该事务时，协调器将回复参与者abort该事务的命令。

2、在协调器发送commit后崩溃。这种情况，我们不允许协调器忘记该事务的信息，因为该事务已经提交并可能已经将执行结果返回给客户端，部分参与者可能已经收到commit消息进行本地持久化了。那么采取的措施同上，就是协调器在发送commit之前必须要先将该事务的信息保存到本地磁盘，即使崩溃重启后协调器也可以读取磁盘上的日志来获悉被提交的事务的信息，并重新给参与者发送commit消息，获取参与者当前的情况，如果收到了所有参与者的ack回复，那么就表明所有参与者都已经完成该事务就持久化，随后即可在在日志中删除该事务相关的数据。

超时机制的设定

在分布式系统中，当发送消息给对方，迟迟收不到回复，那么就有两种可能，一种可能是网络问题导致数据包的丢失或者是延迟，另一种可能是对方服务器已经崩溃了。这种情况下，一方需要等待另一方的回复，在这个过程中，锁始终被这个事务所占有，这可能会导致其他事务处于等待状态，为了避免等待时间过长，设定了超时机制。

如果事务协调器在发送给参与者的prepare包丢失或者是参与者崩溃了，协调器在收不到回复的情况会再次发送包给参与者。如果协调器在规定时间内始终没有收到参与者的回复，那么协调器就会单方面终止该事务，发送abort给参与者，并将该事务的信息删除，参与者前来咨询该事务的情况，也会被告知协调器处并无该事务的信息，并要求abort。

超时机制不能触发的特殊情况

当参与者回复prepare消息，发送ok给协调器后，迟迟无法收到后续的commit消息，在这种情况下，即使事务保持等待阻塞占有锁，也不能单方面的终止事务，因为在参与者回复ok后，这个事务就有可能是提交状态的，参与者必须一直等待下去。

二阶段提交的缺陷

阻塞等待

阻塞等待是二阶段提交机制的一个特性，然后这个特性会给性能带来很大的问题，如果参与者长时间的等待协调器的commit消息，就会严重阻碍其他事务的执行。因此人们为了解决这个阻塞等待，都在努力让二阶段提交的过程中的这一部分的流程（如图所示）执行的尽可能快，尽量缩短由于协调器发生故障带来的阻塞等待时间。

人们会让这一部分变得十分轻量，有些改进版的二阶段提交协议中，在特殊情况下，参与者甚至无需等待协调器的回复。

两阶段提交协议是一个十分基本的协议，它之所以能够允许一个事务中的多台参与者服务器同时提交事务或者是终止事务，实现事务的原子性，其中一个原因就是这个决定是由一个中心化的单体---事务协调器来决定的。这些决定并非是参与者决定的，参与者之间无需进行通信来达成一致决定什么东西，仅需听从事务协调器的命令即可。

这样的设计的代价就是，在某些情况下，参与者必须要等待协调器的命令才能继续后续的步骤，参与者无权对事务做出决定，只会阻塞等待协调器后续的命令：提交或终止事务。

速度慢

为了实现分布式事务的原子性提交，二阶段提交机制需要多轮的消息通信，来确保让涉及的多个参与者同时提交或终止事务。

此外，这流程中多处还涉及磁盘的写入操作，磁盘写入操作需要耗费大量的时间，这会严重限制事务的处理速度，可能一个事务的处理时间绝大多数由磁盘写入时间占据。这个磁盘写入速度也成为了事务处理速度的关键影响因素。

事务协调器和多台参与服务器将一起受到故障波及

因为阻塞等待行为的存在，组织间在处理分布式事务时也不会使用二阶段提交机制，例如：涉及不同银行账号之间的转账行为。因为这个机制会使得一个组织的服务器上的数据库可被其他组织干涉。

一个组织可以通过让本组织的服务器在错误的时间发生崩溃，让其他组织的服务器上数据库被迫长时间持有锁。

因此，基本不会有不同的组织间会使用二阶段提交机制，这个机制一般就用于一个机房或者是一个小组织。

Raft和二阶段提交的对比

raft中，leader和follower之间只要有超过半数的follower收到了leader的消息，leader即可提交。这一对比，似乎二阶段提交也可以进行借鉴，但是实际上，这两个协议存在本质的差别。

raft目的是为了提高可用性，它让数据进行复制到多台服务器上，来获得高可用性，即使某些服务器发生了崩溃，也有其余的冗余复制体来顶替服务。

但是二阶段提交服务于分布式事务，分布式事务是为了提高性能，将一个事务的操作划分到了多台服务器上并行进行，不同参与者之间的任务是不同的，因此必须要确保所有参与者都完成了任务，才能进行事务的提交。二阶段提交其实和raft没有什么关系。

但是二阶段提交的缺点可以通过raft来弥补，二阶段提交中服务器的低可用性导致服务器崩溃，从此带来阻塞等待。这种低可用性可以通过raft来提升。

因此raft和二阶段提交可以结合使用。