分布式事务实现-Spanner
Spanner要满足的external consistency是指：后开始的事务一定可以看到先提交的事务的修改。所有事务的读写都加锁可以解决这个问题，缺点是性能较差。特别是对于一些workload中只读事务占比较大的系统来说不可接受。为了让只读事务不加任何锁，需要引入多版本。在单机系统中，维护一个递增的时间戳作为版本号很好办。分布式系统中，机器和机器之间的时钟有误差，并且误差范围不确定，带来的问题就是很难判断事件发生的前后关系。反应在Spanner中，就是很难给事务赋予一个时间戳作为版本号，以满足external consistency。在这样一个误差范围不确定的分布式系统时，通常，获得两个事件发生的先后关系主要通过在节点之间进行通信分析其中的因果关系(casual relationship),经典算法包括Lamport时钟等算法。然而，Spanner采用不同的思路，通过在数据中心配备原子钟和GPS接收器来解决这个误差范围不确定的问题，进而解决分布式事务时序这个问题。基于此，Spanner提供了TrueTime API，返回值实际为一个区间[t-ε,t+ε]，ε为时间误差，毫秒级，保证当前的真实时间位于这个区间。
Spanner是一个支持分布式读写事务，只读事务的分布式存储系统，只读事务不加任何锁。和其他分布式存储系统一样，通过维护多副本来提高系统的可用性。一份数据的多个副本组成一个paxos group，通过paxos协议维护副本之间的一致性。对于涉及到跨机的分布式事务，涉及到的每个paxos group中都会选出一个leader，来参与分布式事务的协调。这些个leader又会选出一个大leader，称为coordinator leader，作为两阶段提交的coordinator，记作coordinator leader。其他leader作为participant。
数据库事务系统的核心挑战之一是并发控制协议。Spanner的读写事务使用两阶段锁来处理。详细流程下图所示。
如第一段所述，给事务赋予一个时间戳版本号是这样一个分布式存储系统的核心。下面先说如何确定读写事务的版本号，再说只读事务。
前面已经说了两阶段提交过程中两阶段锁的过程，这里就省略这些，只讨论两阶段提交过程中如何确定最后的读写事务的时间戳版本号。
读写事务
简要时序图如下：
图中，commit wait分为两段，第一阶段是论文中4.1.2节提到的Start，第二阶段是4.1.2节的Commit Wait
只读事务
调用TrueTime API，将右区间作为只读事务的版本号,记作Sread, 如果读事务涉及到的副本不够新，那么读会阻塞。每个副本会维护一个时间戳Tsafe, 如果Sread <= Tsafe ，则这个副本够新。Tsafe取两个时间戳的更小值，第一个是副本所在的paxos group中已经apply到状态机的时间戳，第二个是paxos group中leader目前正在参与的还没有commit的分布式事务在该paxos group的最小的prepared timestamp - 1。
还有一种方法，可以不用客户端等，方法是Sread通过客户端和所有涉及到的paxos group的leader进行协商，每个leader返回他们的最后一次事务的commit时间戳给客户端，然后客户端取最小的版本号作为Sread即可。
下面说一下两阶段提交的错误处理。
两阶段提交协议由于协调者和参与者的故障可能会有严重的可用性问题。Spanner的两阶段提交实现基于Paxos协议，每个participant和coordinator本身产生的日志都会通过paxos协议复制到自身的paxos group中，从而解决可用性问题。同样以A，B，C三份数据为例，他们分别有三个副本，记作(A1，A2，A3)，(B1，B2，B3)，(C1，C2，C3)，每组作为一个paxos group，内部通过paxos协议保证一致性。假设，A1，B1，C1分别为各自paxos group的leader，A1为coordinator leader。
Prepare阶段：A1给B1和C1发送prepare消息后，假设B1挂了，A1等待超时，A1给C1发送rollback。B1后续回滚分为两种情况：1. B1在持久化prepare消息之前挂了，B1恢复后可自行回滚 2. 如果B1持久化prepare消息之后挂了，B1自身可以回放日志得知事务未决，主动联系(A1,A2,A3)。A1给B1，C1发送prepare消息之后，自己挂了，同样，A1通过回放日志可以得知。实际上，A1本身挂了之后，A2和A3通过选主协议马上会选出一个新的leader，不至于影响到可用性。
Commit阶段：A1给B1，C1发送commit消息，B1 commit成功，C1挂了，C1起来后，如果C1之前没有持久化commit消息，则A1主动要求C1继续commit。如果C1之前已经持久化了commit消息，则自己commit。如果C1由于某些原因，始终commit不成功，则由上层业务进行回补操作。
参考资料
Spanner: Google’s Globally-Distributed Database
presentation:Spanner: Google’s Globally-Distributed Database
