「分布式技术专题」并发系列三：乐观并发控制之原型系统（分布式验证）

原型系统——分布式验证

Centiman: Elastic, High Performance Optimistic Concurrency Control by Watermarking 2015

concurrent8

Centiman是一个在云环境基于NoSQL存储层+事务处理层（OCC）实现的具备串行化事务隔离级别的KV系统，由KV存储、事务处理子系统（包括处理结点和验证结点）、全局总控结点及客户端组成。

一个事务的完整生命周期分为如下阶段：

读取阶段

处理结点维护一个本地的已应用事务提交时间戳（watermark，此时间戳之前的数据更新已写入kv存储）及其它节点已应用事务提交时间戳的缓存（缓存定期异步更新）
每次读操作读取最新版本的kv，处理结点会计算最新的watermark时间（取全局最小），将key、version、watermark记入读集；写入操作需将kv缓存到处理结点的事务私有内存空间并将key记入写集

• 验证阶段
只读和读写事务都需要走验证流程（优化：处理结点若发现待验证事务的所有读时间戳都小于事务第一次读时的watermark，则直接向客户端返回提交）
处理结点给待验证事务赋值一个全局单调递增的提交时间戳
将执行阶段记录的读集、写集按照key的某种分片规则分别发送到对应的验证结点，同时将事务私有内存中的数据异步写日志
每个验证节点维护一个滑动时间窗口，小于滑动时间窗口到来的验证请求则直接返回验证失败；落在滑动窗口内的验证请求按照事务提交时间戳顺序进行处理并持续推进滑动窗口
采用BOCC算法进行验证，对于事务在某个分片验证节点读集中的每个key, 在验证结点缓存的事务写集中查找所有在读key时间戳和待验证事务提交时间戳之间提交的事务并验证读key是否与已提交事务的写集冲突 （优化：如果读key时间戳小于记录的watermark时间戳，则冲突检查区间可以缩小为在watermark时间戳和待验证事务提交时间戳之间）
若冲突，则中止事务；否则，将待提交事务的写集缓存在验证节点用于后续新事务的验证并提交事务
如果所有相关验证结点都同意提交事务，则发起验证的处理结点写提交日志并通知客户端，转入写入阶段；否则直接通知客户端事务已中止（可能存在有些验证结点认为应该提交，有些验证结点认为应该终止的状态，虽然事务整体是终止状态，但部分验证结点会存在冲突误判，论文中也是依赖watermark机制尽量减少误判）

• 写入阶段
处理结点将事务本地内存中的更新内容写入kv存储（写入过程不要求保证原子性，允许其它事务读到部分写入的新值；通过kv存储的MVCC机制保证提交时间戳靠后的事务写入的数据不会被提交时间戳靠前的事务写入的数据覆盖）
待全部写入成功后，更新本地watermark并异步记录事务已完成日志
这个系统的实现架构是具有一定代表性的，所有不支持ACID事务的NoSQL系统都可以参照此原型架构实现串行化事务隔离级别，后续我们要研究的FoundationDB架构也与此类似，当然生产环境的数据库还会考虑更具体的问题，比如幻读的处理、性能优化等。
至此，本文列举了OCC在这一时期在学术及工业界的主要结果，可以看出主要是性能优化，扩展性提高及生产级系统的实践。这里也忽略了一些有代表性的OCC系统，比如Percolator[13]、Silo[17]，因为这些系统在并发控制实现中使用了锁机制并存在写读阻塞的情况，虽然可以降低事务中止率，但却违背了OCC读写不阻塞、没有死锁的理念。
相比于前世理论研究的玩具，应用场景的缺乏，今生在内存及分布式数据库场景的落地，理论与工业界不断地性能优化等方面屡有建树，其技术带来的实际使用价值正越来越多地得到系统架构设计人员的认可，尤其是在跨分区、跨数据中心、跨地域分布式事务[22]，实现串行化隔离级别等现今分布式数据库尚未深入触碰的领域有着巨大的挖掘潜力。

结语

本文按照时间线简要回顾了OCC从诞生、理论研究、原型系统验证到生产系统落地的发展脉络，从中可以看出OCC技术从1980年代初发展至今将近40年的时间了，一路走来磕磕绊绊，从不适用于传统单机数据库，到在内存数据库中落地生根；从不适用于分布式数据库，到完美实现在NoSQL分布式数据库上支持ACID事务，甚至在跨分区事务、跨地域分布式系统的研究中也体现出了巨大的优势，有理由相信OCC技术的乐观、尽量减少事务同步开销的理念在未来的云环境中会有更多的运用。

在梳理OCC发展历程的过程中，笔者也逐渐总结出从技术角度应该如何分析实现了OCC的分布式数据库系统（仍有待完善）：
• 读取阶段
– 是否保证读一致性
– 使用事务私有内存还是共享数据内存
– 私有内存在客户端还是服务端
– 私有内存在服务端是单结点还是多结点
– 私有内存是否存储读入的数据
– 如何尽早发现冲突
• 验证阶段
– 事务提交时间戳如何分配
– 验证算法是BOCC还是FOCC模式
– 验证和写入阶段是否需要原子完成
– 如何解决幻读问题
– 如何降低事务中止率
– 如何避免事务饿死
– 如何降低长事务中止率
– 如何优化只读事务
• 写入阶段
– 是否要求原子性
– 使用了什么样的原子提交协议，2PC、Paxos还是不需要
身为一名程序员，笔者恪守Linus Torvalds大神说过的话：
talk is cheap, show me the code
把OCC在生产系统中落地的只有Microsoft的内存数据库Hekaton和Google的分布式KV数据库Megastore。

以上为分布式技术专题之并发系列三：乐观并发控制原型系统（分布式验证），「分布式技术专题」是国产数据库hubble团队精心整编，专题会持续更新，欢迎大家保持关注。