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

发布了373 篇原创文章 · 获赞 403 · 访问量 203万+

猜你喜欢

转载自blog.csdn.net/Androidlushangderen/article/details/94855843