前言

前段时间忙双11忙到废寝忘食，这期间又被各种奇奇怪怪的小病折腾了半个多月，整个人状态不是很好，博客也连续吃灰到现在，请看官勿怪。好在今天感觉还不错，可以继续写点东西了。

为了应对业务数据的爆炸性增长以及MySQL业务库分库分表现状的各种不便，笔者的团队近期用一周时间突击调研TiDB，并部署了由16个节点组成的TiDB集群，同时开始逐渐探索利用它替代MySQL的可能性。在调研过程中，我们了解到TiDB能够100%支持ACID事务。并且不同于传统的XA，TiDB采用的是Google提出的Percolator分布式事务协议。本文聊一聊Percolator的部分细节，之后的文章再说它在TiDB事务(包括乐观事务和悲观事务)中的具体应用。

从Bigtable跨行事务到Percolator

Bigtable是Google实现的分布式结构化大数据存储系统，我们耳熟能详的HBase就是Bigtable的开源版本实现。其数据模型可以视为多维的、支持MVCC的K-V Map，即：


(row:string, column:string, timestamp:int64) -> data:string

Bigtable原生支持单行事务，即能够保证一行内一个或多个列族上的多个操作的ACID特性。但是，很多情况下用户都需要在单个事务中更改多行数据，只有单行事务显然不够用。而基于Bigtable的分布式特性，跨行事务与单行事务相比更加复杂，需要注意的三个要点列举如下：

  • 必须有精准的全局授时服务，消除服务器之间时钟无法严格同步的影响，从而保证事务的顺序不会错乱；

  • 必须有高效的全局锁机制，保证两个并发的事务不能同时修改一行数据，并且避免事务出现死锁；

  • 必须高效，在实现ACID语义的基础上不能影响原有系统的吞吐量与并发度。

在这三个要点的基础上，Google的大佬们又设计了Percolator分布式事务协议，借助Bigtable原生的单行事务实现了跨行事务。Percolator的设计理念集中体现在OSDI 2010的一篇论文《Large-scale Incremental Processing Using Distributed Transactions and Notifications》中。下图示出启用Percolator之后的Bigtable服务架构。

     

 Bigtable依靠Chubby(等同于ZooKeeper)提供分布式协调服务。图中的每一个大矩形表示一台服务器，其上运行的服务包括Tablet Server(等同于HBase RegionServer)、Chunk Server(等同于HDFS DataNode)，以及新加入的Percolator Worker。另外，还引入了Timestamp Oracle(简称TSO)作为全局授时服务。也就是说，Percolator的实现仅需要增加2个服务，以及在客户端提供与Percolator协议兼容的库。

Percolator事务流程

Percolator事务分为两个阶段：预写(Pre-write)和提交(Commit)，本质上相当于一个加强的2PC。另外，所有启用了Percolator事务的表中，每一个列族都会预先增加两个列，分别是：

  • lock：

    存储事务过程中的锁信息；

  • write：

    存储当前行可见(最近一次提交)的版本号。

    为了避免混淆，在这里不将其称为时间戳。

另外，为了简化场景，假设存储用户数据的列只有一个，名为data。

预写阶段

  1. 客户端启动事务，从TSO获取时间戳，记为start_ts，并向Percolator Worker发起Pre-write请求。

  2. 在该事务包含的所有写操作中选取一个作为主(primary)操作，其余的作为次(secondary)操作。

    主操作将作为整个事务的互斥点，标记事务的状态。

  3. 先预写主操作，成功后再预写次操作。


    在预写过程中，对每一个写操作都要执行检查：

  • 检查写入的行对应的write列版本号是否晚于start_ts，如果是，说明有版本冲突，直接取消整个事务；

  • 检查写入的行对应的lock列是否有锁，如果有，说明其他事务正在写，直接取消整个事务。

  1. 检查通过后，以start_ts作为版本号将数据写入data列，但不更新write列，亦即此时写入的数据仍然不可见。

  2. 对操作行加锁，即更新lock列的锁信息：

    主操作行的lock直接标为primary，次操作行的lock则标为主操作行的行键和列名。

注意：处理每一行时，上述步骤3、4、5每次都会在同一个Bigtable单行事务中进行，保证原子性。

提交阶段

  1. 客户端从TSO获取时间戳，记为commit_ts，并向Percolator Worker发起Commit请求。

  2. 检查主操作行对应的lock列所在的primary标记是否存在，如果不存在(可能已经被清理，见后文所述)则失败，取消事务；

    如果存在则继续。

  3. 以commit_ts作为版本号，将start_ts更新到write列中。

    也就是说在本阶段完成后，预写阶段写入的数据将会可见。

  4. 对该行解锁，即删除lock列的锁信息。

  5. 若步骤1~4均成功，说明主操作行成功，代表整个事务实际上已经提交。

    接下来只需异步地提交每个次操作即可，即重复步骤3、4的更新write列和清除lock列操作。

注意：上述步骤2、3、4会在同一个Bigtable单行事务中进行，保证原子性。另外，如果次操作的提交失败，则仍然要回滚事务。

示例：经典转账流程

下图来自原始论文，描述了Percolator协议下的一次转账流程(Bob向Joe转账$7)。注意每一列中冒号之前的是版本号，冒号之后的则是该列存储的数据。附带的说明清楚易懂，笔者就不多废话了。

 

 

漫谈Google Percolator分布式事务_java   

要点简析

快照隔离级别

传统关系型数据库中定义的隔离级别有4种(RU、RC、RR、S)，而Percolator提供的隔离级别是快照隔离(Snapshot Isolation, SI)，它也是与MVCC相辅相成的。SI的优点是：

  • 对于读操作，保证能够从时间戳/版本号指定的稳定快照获取，不会发生幻读；

  • 对于写操作，保证在多个事务并发写同一条记录时，不会有多于一个事务提交成功。

SI下的事务都会带有两个时间戳，即上文讲解Percolator流程时提到的start_ts(下图中空心方块)与commit_ts(下图中实心圆点)。SI硬性要求一个事务提交时的commit_ts大于所有之前产生的start_ts和commit_ts，当然这已经由TSO来保证了。

漫谈Google Percolator分布式事务_java_02 

   

看图说话：

  • 因为start_ts[2] < commit_ts[1]，所以事务1的结果对事务2不可见；

  • 因为start_ts[3] > commit_ts[2] > commit_ts[1]，所以事务1和2的结果都对事务3可见；

  • 如果事务1和2写了同一条记录，那么1和2中至少有一个会失败。

SI存在的主要问题是写偏斜(Write-skew)，看官可自行查找资料去了解，不再赘述。

分散的锁机制

由上文的描述可以看出，Percolator巧妙地反其道而行之，把事务相关的锁信息分散到了每一行中，并通过将主操作作为互斥点，免去了重新设计一套全局锁机制的麻烦。另外，预写阶段的步骤3中检查到任意锁冲突都会取消事务，简单粗暴地避免了死锁的发生。最后，Percolator构建在带冗余的分布式文件系统(论文的语境中是GFS)之上，所以不必担心锁信息会丢失。

快照读与锁清理

相对于写流程，读流程就简单很多了：从TSO获取当前start_ts，然后检查lock列，判断早于当前start_ts的区间内是否有锁。如果没有，则从write列中根据commit_ts获取到最新提交的start_ts，再根据获取到的start_ts从data列中获取数据。如果有锁，则意味着存在未提交的事务，需要等待持锁的事务提交，才能读取最新的数据。读流程也是在Bigtable单行事务中进行的。

这里会产生两个问题：

  • 第一，为什么不能在有冲突时直接返回版本号小于当前start_ts的最新版本数据？

很显然，基于持锁事务结果的不确定性(可能提交也可能回滚)，这样会打破SI对读操作的保证，亦即产生幻读。看官稍稍思考一下即可理解。

  • 第二，如果客户端崩溃或者失联，导致它发起的事务的锁遗留下来，读操作一直不能成功，该怎么办？

答案是由读操作来自主完成，即不会无限等待下去，而是在一定时长的延迟之后直接将卡住的主操作锁信息清理掉，并读取最新版本的数据。

分两种情况讨论：其一，读操作直接读到了原事务中具有primary锁信息的行，说明原事务未提交成功，需要回滚(即清理锁)；其二，读操作读到了原事务中具有secondary锁信息的行，此时仍然要去对应的primary行上查找锁是否存在，如果存在，说明原事务未提交成功，将其回滚；如果不存在，说明已提交成功，将其前滚(即清理锁的同时更新对应的write列)。

可见，主操作锁和从操作锁存在的紧密关联能够有效保证Percolator事务的安全性与活性，即：同一事务中的任意两个写操作结果肯定一致，且所有操作的结果要么是提交成功，要么是提交失败。

客户端的作用

如果套用2PC的概念，客户端(在TiDB内部是tikv-client)显然扮演了协调者(Coordinator)的角色。传统2PC的协调者存在单点问题，但是Percolator中的客户端并没有此问题——就算客户端失败，事务也只会有成功与失败两种状态，不会破坏一致性。

有缺点么？

当然有。

  • 网络I/O和RPC的负载较大，事务预写成本较高；

  • 依靠读操作清理锁，如果清理不及时，会增加其他正常事务写冲突的概率；

  • Percolator锁的本质为乐观锁，如果大量事务并发写热点数据，则根本无法阻塞，造成回滚风暴。

  • 考虑另一个场景：

    有一个大事务和很多小事务，且它们的热点overlap，那么大事务可能受小事务的影响进入饥饿状态(即很长时间内无法执行)。

    为了克服该问题，TiDB提出了悲观事务模型，不过这就是后话了。


The End

写了这么多，似乎找回一点手感了，2020年剩下的这二十多天慢慢恢复更新吧。

民那晚安晚安。