Ozone的数据延迟处理机制

前言

---

在典型的基于DBMS的管理系统中，业务上的请求操作最终会转化为CRUD操作被apply到后台的数据库里。从客户端数据请求的发起再到最终结果的apply，在设计上整个过程往往是同步的方式，因为客户端要知道最终结果是否已经成功更新到数据库里了。类似在其它不是基于DMBS的存储系统中，这种同步处理的方式也是非常常见的。不过，笔者今天要探讨一种对此更为高效的改良设计，来提高数据请求处理的效率，客户端能够得到更快的响应。

传统同步模式的数据处理过程

---

在传统的软件系统中，数据请求处理返回整个一系列过程是同步的进行的，中间的任何一个环节出错都将宣告此次数据操作的失败。以下是其中的处理过程图：

上图对应步骤操作如下：

1)客户端发起数据操作请求
2)中心Manager服务端进行相关条件判断
3)如果条件判断通过，则进行后台DB数据更新，否则Manager返回失败结果给客户端。

上述的过程步骤其实并不多，但是决定整个请求处理过程的快慢经常会发生于最后的DB数据更新这一步。因为DB数据更新涉及到和外界服务进行交互，如果DB服务反应慢了，整个过程的时间也就变长了。试想一下，假设我们把比较重的数据落DB的操作从这个环节中剥离出去，独立地执行，那就可以提高不少的处理速度了。

我们姑且定义上面的过程为数据的延迟处理操作。在最近Hadoop Ozone的OzoneManager的代码实现中，就实现了这么一套延迟处理逻辑。下面我们来聊聊里面的具体实现细节。

Ozone的数据延迟处理机制

---

在Hadoop Ozone中，元数据所采用的DB存储是RocksDB。对于RocksDB的put操作，对应物理操作上是磁盘的写操作。所以假设我们对Ozone元数据进行每次RocksDB PUT更新操作的话，那就可能出现PUT操作执行缓慢的问题。

Ozone在此实现了基于Table Cache+DoubleBuffer的组合设计来达到数据落地延迟处理的效果。可能有同学会好奇，为什么数据写出可以被延迟处理呢，那用户如何知道数据到底是否被成功执行然后存在于DB中了呢？

在这里Ozone系统其实假设的一点是数据写出RocksDB的过程是一直成功的(笔者认为这个假设还是过于理想，因为如果出现前面步骤成功，此步骤失败，会出现脏数据的情况)，只有当前面验证步骤出现失败的时候，才会导致整个处理过程失败。所以当Ozone Manager在请求数据处理的条件验证都通过的时候，就可以马上返回给客户端一个response结果，无须等待数据完全写出到DB之后。因为后面这个过程是异步延迟进行的。

Table Cache：数据的即时可见性

但是为了保证数据对后续数据请求的即时可见性，我们要能够让数据的变更及时的体现出来，所以Ozone在此实现了Table Cache的概念。简单的来说，就是Ozone Manager在返回给客户端response之前，会把数据的变化更新到对应表的Cache中。这里Table的实现类是Ozone内部读写数据到RocksDB的对外操作类。Table Cache被额外地实现在了这个类里，主要更新了里面的get key的逻辑，首先将会从cache中查询，如果查不到再从真实的RocksDB表中进行查询。

Table Cache并不需要一直保存写入的entry值，当更新的entry被真正写出到RocksDB之后，对应Cache中的此项entry其实就可以被移除出去了。所以这里我们要有一个属性能够标记这些entry的先后顺序，然后进行移除，Ozone在这里使用的是transaction id。每次在清理Table Cache，它将所有小于当期写出DB的最大的transaction id的那些entry全部移出Cache。在此清除策略下，Table Cache也就不会持续扩展，占用大量的内存空间了。

DoubleBuffer：基于双缓冲的数据写出过程

---

Ozone Manager在返回给客户端response之前，同时也会把这个response信息加入到缓冲中。然后由另外的线程将缓冲中的response数据变更flush到db中。为了增大flush db过程的吞吐量，Ozone采用的是DoubleBuffer模式，类似于目前HDFS Editlog的flush原理。在每次缓冲区flush出去之后，会把上节提到的Table Cache进行entry移除更新。

由于篇幅有限，这里不具体介绍DoubleBuffer的运行原理，感兴趣的同学可阅读笔者之前写过的一篇相关文章：存储系统双缓冲设计模式。

总体上看，Table Cache+DoubleBuffer的设计来达到延迟处理的目的还是非常巧妙的，下图是Ozone数据请求延迟处理的流程处理图(下图中的（3）步骤中的add/delete entry指的是往Table Cache里添加add/delete类型的entry)：

引用

---

[1].https://blog.csdn.net/Androidlushangderen/article/details/90341093
[2].https://issues.apache.org/jira/browse/HDDS-1499. OzoneManager Cache
[3].https://issues.apache.org/jira/browse/HDDS-1512. Implement DoubleBuffer in OzoneManager