percolator分布式事务简介

背景

我们知道分布式事务常见的实现是通过两阶段提交来完成，其中比较核心的是在这个过程中需要有一个全局的时钟来比较各个操作的先后顺序，此外还要应付协调者进程在这个过程中出现的各种宕机等异常，本文就来了解下Percolator协议是如何比较好的通过两阶段提交协议实现分布式事务的.

技术实现

我们首先看一下percolator协议的示意图

主要的角色如下：
percolator客户端充当协调者角色，中心化的时间戳服务器提供全局单调递增的ID服务，HBASE的各个RegionServer充当参与者的角色.
主要的步骤如下：
1.percolator客户端首先从中心化ID服务器获取一个id，记为start_ts，作为prepare准备阶段的时间戳
2.执行分布式事务的第一个阶段，prepare准备阶段，也就是percolator客户端发送start_ts时间戳给各个RS参与者，RS服务器参与者把要写的数据连同start_ts时间戳写到自身的表中，如上图所示的data列，其中版本号就是start_ts字段,不过新增的这一行数据的这个start_ts版本还不能对外可见，也就是data_visible_version对外可见的版本号这一列不能修改成start_ts，此外标识该行处于锁定状态
3.percolator客户端向中心ID服务器发送请求获取一个Commit阶段的时间戳commit_ts
4.执行分布式事务的第二阶段commit数据，也就是percolator客户端发送commit_ts时间戳给各个RS参与者，RS服务器参与者要把第一阶段中写入的数据(版本号为start_ts)的数据对外可见，也就是修改表的data_visible_version列，设置为start_ts，表示该行数据对其他事务可见,并清理该行的锁定信息

关键点:

这个过程中关键点是协调者(pecolator客户端)在prepare准备阶段结束后，而在第二阶段commit提交前发生宕机怎么办？如果出现这种情况，那么此时表中的记录是处于锁定的状态，其他的事务没法操作这一行记录，那么这里percolator协议怎么处理这种情况的呢？
答案是当client正常get请求过来获取这一行数据的时候，如果发现记录锁住，并且锁定的时间超出阈值，（这里如何判断锁定时间超出阈值呢？最简单的就是用RS服务器当前的时间戳减去该行记录最近一次更新的时间戳，如果严格的就是要向ID时间服务器获取当前的时间戳ID，然后用这个时间戳ID减去这行记录的start_ts时间戳ID）,则认为事务失败并回滚，否则get请求继续循环等待.