其他分享
首页 > 其他分享> > Ozone BlockCommitSequenceId在Container上的运用

Ozone BlockCommitSequenceId在Container上的运用

作者:互联网

文章目录

前言


在Ozone中,Container以Pipeline节点组织的方式通过StateMachine的形式进行状态一致性的更新。不过这里面对可能存在的一些边缘情况,例如Pipeline节点的突然重启,Container目录的意外删除,我们需要有别的手段来表明Container当前所处于的最新状态。以此我们可以知道一个Container存储于Pipeline节点上的副本间的状态是否是一致的,是否包含一致的Block数据等等。为此,社区在Container中引入了一个自增型的transactionId,表明当前Container的最新的状态。本文笔者来聊聊这个自增型transaction ID在Ozone Container中的实现和运用。

Ozone Container自增型TransactionId:BlockCommitSequenceId


这里笔者要首先介绍介绍Ozone Container自增型Id的由来了。在Ozone中,Container是面向外部提供Block数据存储的单元,其内部会接受来自于外部Block的数据读写请求。简单来说,一个Container在其空间还有富余的情况下,会有外部源源不断的Block的数据写入。鉴于同一Container不同副本所在机器可能存在的通信,网络的延时,会存在数据写入快慢的问题,因此Container在同一时间所处于的最新“数据状态”会有所不同。如果我们把每一次操作当作一个Transaction的话,执行了最新Transaction的Container会有最新的“数据状态”。不过,最终这些Container的副本会执行完写入的Transaction操作,然后达到最终一致的“数据状态”。

那么问题来了,在Ozone中,我们如何实现这样的TransactionId呢?它需要保证每个操作Id在Pipeline节点的Container内是具有唯一性的。在Ozone中,Datanode是通过Apache Ratis+ContainerStateMachine的方式实现了Container操作一致性的控制,而ContainerStateMachine本身是会apply来自于Raft server的Raft log,我们可以充分利用Raft log id作为Container的Transaction更新Id。这样的话,我们也无须另外生成专属于Container的TransactionId。在这里,Ozone将这个TransactionId称为BlockCommitSequenceId,意为每次Block数据写完提交后的Id。

BlockCommitSequenceId遵循以下的原则:

同一Container的多个副本的最终BlockCommitSequenceId是一致的,意为最终Container“数据状态”的一致性。如果有小于Container当前最新的BlockCommitSequenceId的id transaction在写入的时候,说明此Block数据之前已经被写入过了,可以忽略此写入操作。

BCSID(BlockCommitSequenceId的简称)除了在Container层面进行了更新外,还会被记录在每次的Block数据中,以Id的属性形式保存在Block信息中。

此过程转化图如下所示:
在这里插入图片描述
上图显示BCSID除了在Container上会维护一个最新的值外,每次的写入的Block数据中也会带有一个相应的BCSID。

BlockCommitSequenceId的使用用途


BCSID是被记录并更新在了Container中了,那么它有哪些额外的使用用途呢?

根据BCSID在Ozone内的使用场景,它至少有以下用途:

引用


[1].https://issues.apache.org/jira/browse/HDDS-1843
[2].https://issues.apache.org/jira/browse/HDDS-935
[3].https://issues.apache.org/jira/browse/HDDS-603

标签:Container,BlockCommitSequenceId,Ozone,BCSID,数据,Block
来源: https://blog.csdn.net/Androidlushangderen/article/details/104736032