一文搞定Journal Node原理
【概述】hdfs的HA机制，具体来说可以分为两部分，一部分是基于zkfc、zookeeper完成nn之间的选主；而另一部分则是nn之间的元数据共享与同步。从hdfs2.0版本开始，引入了H...
【概述】
hdfs的HA机制，具体来说可以分为两部分，一部分是基于zkfc、zookeeper完成nn之间的选主；而另一部分则是nn之间的元数据共享与同步。
从hdfs2.0版本开始，引入了HA using Quroum Journal Manager（QJM）方案。
QJM的思想最初来源于paxos协议。在具体实现中，Journal Node（JN）集群作为NN之间editlog的一致性存储系统，也是HDFS高可用方案中的核心组件。
通过JN，ANN可以尽可能及时的将元数据同步到SNN，ANN通过push的方式将editlog写入JN集群，而SNN通过pull的方式从JN中读取editlog，JN之间彼此不主动进行数据的交互。
由于paxos协议的关系，读写JN都要求至少大多数节点成功返回才认为本次请求是成功的。另外，2N+1台JN组成的集群，最多可以容忍N个JN节点异常。因此整体具有很强的HA能力。
本文就其中的一些细节展开进行说明。
【JN中的概念与持久化文件】
一些概念：
epoch
epoch是paxos协议中的一个概念，可以用于标识leader。
而具体实现中，epoch是一个单调递增的整数，用来标识每一次ANN的生命周期，每发生一次NN的主备切换，epoch就会加1。
ANN后续的每个请求中，都会携带epoch，同时JN会对请求进行校验，如果携带的epoch比本地存储的小，则抛出异常；而如果携带的epoch比本地存储的大，则更新本地的epoch。
这就意味着，不管怎样进行NN的切换，任意时刻都只能有1个NN成功写JN。
txid
每条写入的editlog都有一个对应的递增的事务ID。
segment
多个连续的事务（txid）组成一个segment，持久化到一个对应的editlog文件中。
这样，对应到具体实现中， 任何时间，JN上只会有一个segment处于正在写的状态（Inprogress），而其他的segment文件则都处于写完关闭的状态（Finalized）
JN中的持久化文件：
|-- current
| |-- committed-txid
| |-- edits_0000000000000000001-0000000000000000002
| |-- edits_inprogress_0000000000000000003
| |-- last-promised-epoch
| |-- last-writer-epoch
| |-- paxos
| |-- VERSION
|-- in_use.locklast-promised-epoch
有两个地方会写入，一个是ANN发送新的epoch的rpc请求时，会进行更新；另一个是每次editlog的写请求时，会判断请求中的epoch是否比本地的epoch大，如果是则进行更新，否则会抛出异常。
last-writer-epoch
每写一个新的segment时，检查请求中的epoch是比上次写入的epoch大，如果大，则将当前请求中的epoch写入文件中。
committed-txid
处理每个写editlog的事务请求中，同步更新本地记录的事务ID。
edits_$starttxid-$endtxid
已经写完关闭的segment文件，该文件记录了从开始事务ID到结束事务ID的连续的editlog信息。
edits_inprogress_$lasttxid
当前正在写的segment文件，文件名中记录了开始事务ID
VERSION
记录集群的相关信息，包括命名空间ID，集群ID，创建时间等。
【正常读写流程】
1. 格式化
在集群初始化时，首先会进行格式化动作，具体是由NN触发进行的。
JN收到格式化的请求后，先删除editlog存储目录下的所有文件，然后将NN的相关信息写到该目录下的VERSION文件中。
VERSION文件只有在格式化时才会写入，而如果本地没有VERSION，则会认为没有格式化，所有的请求都无法正确处理。
2. 设置epoch
在HA模式下，格式化完成后，两个NN通过zkfc完成选举动作，成为Active的NN首先向JN集群发送getJournalState的RPC请求，JN收到请求后返回自己保存的已经通过的epoch（lastPromiseEpoch）
NN收到大多数JN返回的epoch后，选择其中最大的epoch，并加1作为当前新的epoch，然后向各个JN发送newEpoch的RPC请求（请求中会带上新的epoch）
每个JN收到新的epoch后，首先检查这个新的epoch是否比它本地保存的lastPromiseEpoch大。
如果大的话就把lastPromiseEpoch更新为新的epoch，并且向NN返回自己本地磁盘上最新的一个editlogSegment的起始事务ID，为后续的数据恢复做准备；
如果小于或等于就向NN返回错误，表示该JN接收了更新的提案。
NN收到大多数JN对newEpoch的成功响应之后，就会认为生成新的Epoch成功。
在此之后进行editlog的恢复动作（对于新部署的，或者正常结束的集群，不会触发进行），这里暂时不展开，后面会讲解
完成恢复之后，则可以进行editlog的写入。
3. 读写editlog
ANN向JN写editlog的流程其实比较简单，就是向所有JN发送一个RPC请求，当收到多数节点的成功响应后，认为本次editlog的写入是成功的。
从JN中读取editlog的工作，则是在SNN中发生的。
SNN启动后，内部会创建一个EditLogTail的线程。具体读逻辑包括下面四个步骤
1）向所有JN请求从指定事务之后的editlog文件集合
2）对所有返回的editlog文件清单，按起始事务ID进行排序，并去除重复的文件
3）依次向editlog文件对应的jn发送请求，通过Http下载editlog文件
4）对下载后的editlog文件，依次读取每一条editlog并进行动作重放，即更新内存中inode、block等元数据信息。
注意：SNN的EditlogTail会定时读取从JN读取editlog信息，读取editlog并进行对应的重放后，只是在内存中对元数据进行了更新，并没有实际持久化到本地盘中。
如下图所示：
并且从nn的日志中可以看出是有定时请求读取editlog信息的。
只有在定时触发checkpoint的时候，此时会再次读取editlog的信息（每次读取后在内存中更新了最新的事务ID，如果异常重启则是从本地文件中读取最后更新的事务ID），然后将元数据信息以fsimage的形式存储在本地，同时记录最后一次的事务ID。
【JN异常后的同步】
正常运行过程中，如果某个JN出现了异常，ANN内部会对该JN进行标记，后续不再给该JN发送editlog。直到触发进行滚动日志操作，此后如果异常的JN恢复正常，则继续向该JN写editlog。
也就是说，当JN出现异常后，ANN先标记该JN为异常，后续的editlog不写入。正在写入的editlog会有重试机制继续尝试；另外，当开始写新的segment文件时（滚动日志），如果该JN已经恢复正常，则接着写入，之前segment没有写入的editlog不会进行补写。
如下所示，JN异常时，从1465开始的editlog没有正确保存到segment文件中，以及之后的一段都因JN异常没有写入。
edits_0000000000000001478-0000000000000001479则是JN恢复正常之后写入的segment文件，中间缺失的editlog不会补偿写入。
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:03 edits_0000000000000001457-0000000000000001458
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:05 edits_0000000000000001459-0000000000000001460
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:07 edits_0000000000000001461-0000000000000001462
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:09 edits_0000000000000001463-0000000000000001464
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001478-0000000000000001479
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001480-0000000000000001481
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001482-0000000000000001483
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001484-0000000000000001485
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001486-0000000000000001487
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001488-0000000000000001489
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001490-0000000000000001491
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001492-0000000000000001493
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001494-0000000000000001495
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001496-0000000000000001497
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001498-0000000000000001499
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:40 edits_0000000000000001500-0000000000000001501
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:41 edits_0000000000000001502-0000000000000001503
-rw-r--r--. 1 hadoop hadoop 42 Oct 19 22:43 edits_0000000000000001504-0000000000000001505
-rw-r--r--. 1 hadoop hadoop 1048576 Oct 19 22:09 edits_inprogress_0000000000000001465
-rw-r--r--. 1 hadoop hadoop 1048576 Oct 19 22:43 edits_inprogress_0000000000000001506【JN异常后的同步】
当ANN出现异常时，通过ZKFC以及ZK，SNN会成为新的ANN，由于原来的ANN异常时，JN集群中的不同节点，其写入的editlog可能不一致，因此新的ANN先要保证所有JN的数据一致后，才能进行写入，这个过程就是JN的数据恢复流程，具体包括如下几个步骤：
1. 向所有JN获取当前的epoch，从结果中选取最大的epoch。
2. 将最大的epoch加1后，作为新的epoch，然后写入所有JN中。
3. 从所有JN获取最新segment的起始事务ID（txid），该步骤实际上是上一步骤请求的响应结果中带回来的，这样就减少了一次rpc请求。
例如下面，两个JN，正在写的segment文件，起始的事务ID均为16，因此在newEpoch的请求中，都返回了16。
4. 从结果中选取最大的事务ID作为参数，然后向所有JN发送prepareRecovery的RPC请求。
5. JN收到请求后，根据自身情况，返回指定起始事务ID的segment信息，包括起始事务ID、结束事务ID、以及当前segment是否为正在写。
接着上图的流程，jn-1中，已经处理了事务ID为28的editlog请求，因此返回16-28。而jn2仅处理到16的事务ID（之前出现了异常，导致后续的editlog没有写进来），因此返回16-16。
6. ANN从请求结果中，选取最优的segment，并组装为URL，包括该segment所在的JN、命名空间信息、以及segment的信息，将该URL作为参数，向JN发送AcceptRecovery的RPC请求，要求进行数据的同步。
7. JN收到请求后，对URL进行合法性校验，然后向指定的JN发送HTTP请求，下载对应的segment。
ann收到请求响应后，选择需要恢复的segment，显然16-28是最新最全的数据，因此将该起始段的segment作为待恢复的数据，发送给所有jn。
jn1收到数据后，发现本地已经是最新的了，因此忽略处理。而jn2发现本地数据有落后，因此解析segment的url，向jn1发送数据同步的http请求，完成数据下载。
8. JN在发送完AcceptRecovery的RPC请求后，会继续向JN发送一条finalizedSegment的请求，要求关闭当前正在写的segment，然后打开新的segment进行写。
对照jn1、jn2的日志也能更好的理解这一流程。
jn1的日志如下图所示：
jn2的日志如下图所示：
【其他常见问题】
JN写editlog是试试刷新到本地磁盘的吗？
不是，JN将editlog写入本地磁盘和NN写editlog到本地是复用了同一份代码，定时触发刷盘。
SNN从JN读editlog是实时读取的吗？
不是，周期性进行读取，默认时间间隔为1分钟。
JN存储的editlog会自动删除吗？
不会，SNN触发执行checkpoint时才会进行删除，同时还会进行一定数量的事务的保存。
【巨人的肩膀和推荐阅读】
1. https://hexiaoqiao.github.io/blog/2018/03/30/the-analysis-of-basic-principle-of-hdfs-ha-using-qjm/
好了，本文就介绍到这里，原创不易，点赞，在看，分享是最好的支持， 谢谢～
权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区
更多推荐
6
0- 0
已为社区贡献1条内容
所有评论(0)