本文共 1752 字,大约阅读时间需要 5 分钟。
众所周知,HDFS在启用HA模式下时,会有一个ANN(Active NameNode),以及一个SBN(Standby NameNode)。它们之间在通过QJM机制实现元数据的信息同步,简单的来说就是ANN将改动的元数据消息记录(editlog)写到JNN(JournalNode)上,然后SBN再从这些JNN上去读这些信息,再apply到自己的内存空间中。以此达到两边元数据的最终一致。其实从这里,我们能够很容易发现一个同步延时的问题,也就是说SBN内的元数据会略微延时于ANN。举个简单的例子,用户在HDFS内创建一个新的文件,然后立即去查询此文件的信息,在ANN上很显然我们能查到结果,但是从SBN上,可能就查不到。我们用一个专业的术语来描述这种现象:Stale Read,译为延时读。换个层面来说,这是一种读不一致性的问题,也是本文所讨论的一个核心问题点。
针对SBN与ANN因为更新延时的造成的读不一致性问题,这是不是一个需要去解决的问题呢?毕竟元数据最终还是会一致的。但是有的时候,我们不能把问题想的这么简单,如果SBN真的能够做到与ANN的一致性读,那么相当于我们多了一个Read-Only的ANN,可以把SBN的RPC处理能力也给利用起来了。至少目前来看,SBN平时基本用不上,就等着failover切换时备着。下面是SBN实现一致性读更加具体化的应用场景:
下面我们来看看SBN实现一致性读的语义定义以及实现细节。
SBN一致性读是社区目前在做的一个全新feature,JIRA链接:,下面内容为笔者对其设计文档的一个小结,感觉还是非常有趣的。
首先来看看SNN一致性读的标准语义定义:
如果一个客户端c看见或修改一个对象obj的状态id为modId1,在t1时间点。然后在未来任何大于t1的时间点t2,客户端c看到的obj的状态id modid2 >= modid1。
实现一致性读的核心思想是等SBN“追上”ANN的脚步,如果本身“落后”太远,则直接将请求重新转向ANN。
逻辑操作语义定义如下:
1.客户端c在内部维护2个lastSeenId,分别对应ANN,SBN:c.LastSeenId.ANN和c.LastSeenId.SBN。这2个id可理解为从客户端c的角度,分别从ANN,SBN所能够看到的最新事务id。
2.如果id c.LastSeenId.ANN <= c.LastSeenId.SBN,转向ANN,并更新 c.LastSeenId.ANN。 3.否则等待直到SBN追上c.LastSeenId.ANN。其它细节要点如下:
ANN<===>SBN<===>ONN
[1]. . Consistent Reads from Standby Node
转载地址:http://long.baihongyu.com/