深入理解分布式事务Percolator(二)

Q2 Read等到一定时间就可以清理掉锁，这样为什么不会影响数据一致性？
A2 清锁的方式是先清理主锁，之后再清理从锁，因为主锁其实是保证原子的基本barrier。而一致性需要从两个方面看，一方面是站在数据服务一侧的视角，对于强一致的数据库，需要满足ACID，Percolator的事务是具有原子性的，由于从锁(secondary lock)和主锁(primary lock)的trick设计，无论你释放的锁处于什么状态，总能通过分析找出某一个write怎么处理能保证原子性。比如对于从锁来说，如果主锁存在，则说明事务还未提交，不能清除自身，想resolve从锁，需要先resolve主锁；如果主锁不存在，则先查询主锁的write列是否有write是指向主锁事务start_ts的data，如果有说明事务提交了，如果没有则说明事务没有被提交，也可能write列有一个rollback的指向了主锁事务start_ts的data，这更显式地说明了事务被cancel了。从锁根据主锁的情况一致地处理自身就行。所以在另一方面是站在客户端一侧的视角，由于当前同时存在读写两个事务，说明客户端使用的时候要么并发了，要么之前有一个请求返回了unknown error(分布式的情况下响应分两种，certain和unknown，certain是服务端给的确定性的结果，无论成功、失败或其他错误，unknown是整个请求链有网络原因导致的未知错误)，这种情况下用户没有等到得到一个确定性的结果之前，就又执行了一个请求，导致了并行。这两种情况无论哪一种对于用户侧都是未知的行为(因为有并行行为)，所以这里清锁(resolve lock)是没有任何客户端视角的一致性问题的，因为本来结果就是一个不确定的未知。综上，不会影响一致性。当然这里隐含了一个问题，那就是写事务是一个长事务，这时候读清理了写事务的锁会导致可用性问题，这可以通过对锁保持心跳更新其deadline阻止清理，这在第三篇实现篇也有说明。