QJM 核心源代码解读 Hadoop namenode 高可用性分析_光环大数据培训

1、 光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/QJMQJM 核心源代码解读核心源代码解读 HadoopHadoop namenodenamenode 高可用性分析高可用性分析_ _光环大数据培训光环大数据培训HDFS namenode 在接受写操作时会记录日志，最早 HDFS 日志写本地，每次重启或出现故障后重启，通过本地镜像文件操作日志，就能还原到宕机之前的状态，不会出现数据不一致。如果要做高可用 (HA)，日志写在单个机器上，这个机器磁盘出现问题，重启就恢复不了，导致数据不一致，出现的现象就是新建的文件不存在，删除成功的还在等诡异现象。这是分布式存储系统不能容忍的。在单机系统上是通过 WAL（write ahead log）日志来保证出问题后可恢复，在 HDFS 上对应的就是操作日志（EditLog） ，用于记录每次操作的行为描述。这里我们简单介绍下 editlog 的格式。文件格式编辑中的日志 edits_inprogress_txid，也就是后文提到的 segment，txid 代表该日志文件的第一个事务 IDFin

2、alized 日志即一致不再更改的日志文件 edits_fristTxit_endTxid内容格式文件头：有版本号 一个事务头标识文件内容1 操作类型 占 1 个字节2 日志长度 占 4 个字节光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/3 事务 txid 占 8 个字节4 具体内容5 checksum 4 个字节文件结尾：一位事务标识注意之前没有 journal 分布式日志时，每次 flush 日志时在该段日志后面加一个标识 INVALID_TXID，在下次 flush 时会覆盖该标识，但目前的版本去掉了这个标识通过 editlog 能做到单机版系统的可靠性，但是在分布式环境下，要保证 namenode 的高可用，至少需要两台 namemode。要做到高可用，高可靠，首先就是保证 HDFS 的操作日志 (EditLog) 有副本。但有了副本就引入了新的问题，多个副本之间的一致性怎么保证，这是分布式存储必须解决的问题。 为此 Clouder 公司开发了 QJM（Quorum Journal Manager）来解决这个问题。J

3、ournal Node 集群Journal node 是根据 paxos 思想来设计的，只有写到一半以上返回成功，就算本次写成功。所以 journal 需要部署 3 台组成一个集群，核心思想是过半 Quorum，异步写到多个 Journal Node。写日志过程editlog 写入到多个 node 的过程简单描述如下：ActiveNamenode 写日志到 Journal Node，采用 RPC 长连接光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/StandbyNamenode 同步已经 Finally 日志生成镜像文件,以及 Journal Node 直接同步数据，采用 HTTPActiveNamenode 每接收到事务请求时，都会先写日志，这个写日志的过程，网上有好多好的文章做分析，这里只是大概说下值得我们学习的地方以及一些好的设计思想。1 批量刷磁盘这个应该说是写日志的通用做法，如果每来一条日志都刷磁盘，效率很低，如果批量刷盘，就能合并很多小 IO（类似 MySQL 的 group commit）2 双缓冲区切换bufC

4、urrent 日志写入缓冲区bufReady 即将刷磁盘的缓冲区如果没有双缓冲区，我们写日志缓冲区满了，就要强制刷磁盘，我们知道刷磁盘不仅是写到操作系统内核缓冲区，还要刷到磁盘设备上，这是相当费时的操作，引入双缓冲区，在刷磁盘操作和写日志操作可以并发执行，大大提高了 Namenode 的吞吐量。恢复数据恢复数据是在 Active Namenode crash 后，standby namenode 接管后，需要变为 Active Namenode 后需要做的第一件事就是恢复前任 active namenode crash 时导致 editlog 在 journal node 的数据不一致。所以在 standby node 可以正式对外宣布可以工作时，需要让 journal node 集群的数据达到一致，下面主要分析恢复算法， 恢复算法官方说是根据 multi paxos 算法 。光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/Multi PaxosPaxos 协议是分布式系统里面最为复杂的一个协议，网上主要都是讲概念和理论，不较少

5、讲实践的，所以写本文也是为了更好的理 paxos。paxos 的资料网上很多，可以看登博最近分享的 ppt，讲得很通俗易懂的。Multi Paxos 是 paxos 改进版，因为 Basic paxos 每一轮 paxos 都生成一个新的 proposal，这一般是由多点写，就像 zk Leader 选举，每个人都可以发起选举。但我们大多数分布式系统都有一个 leader，并且都是有 leader 发起 proposal，那后面就可以用第一次 proposal number，就直接执行 accept 阶段，从 qjm 这个实践里看，有点类似 RAFT 了，都有 leader 的角色。重用当前的提案编号 epoch恢复数据过程：1 隔离2 选择恢复源3 恢复1 隔离开始恢复前需要对前任隔离起来，防止他突然间复活，导致脑裂。隔离的措施是 newEpoch，重新生成一个新的 epoch，算法是通过计算所有 jn 节点中最大的一个，加 1，然后让命令 journal node 集群更新 epoch。更新后，如果前任复活，也不能向 journal node 集群写数据了，因为他的 epoch 比

6、 journal 集群小，都会被拒绝。生成新的 Epoch 代码如下:光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/Hadoop拒绝的代码如下：2 选择一个恢复源隔离成功后，需要选择一个副本来恢复，每个 journal 的最新的 segment 文件不一致，因为 namenode crash 的时间不同而不同。所以需要从 journal 集群中最新的副本的信息。3 恢复隔离成功后，就开始恢复。在分布式系统，为了使各个节点的数据达成一致，经典的算法还是 Paxos，根据 Paxos，分为 2 阶段分别说明如下：QJM 的两阶段对应的是 PrepareRecover 和 AccepteRecover，注意这里说是 Paxos 上文说是 Multi Paxos，区别就是 epoch 重用的。核心算法还是 Paxos。3.1 PrepareRecovery向所有 journal node 发送提议，并选中一个恢复的 segment，返回 segment 如下信息：是否有 segment有 segment，则附加 segment 的状态

7、committedTxnId 该 journal node 已经提交的事务 ID，QJM 每次日志同步后，会更新每个 AsyncLogger 的 committedTxnId，journal node 也每次请求都检查传过来的 光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/committedTxnId，如果大于，则更新到本地。lastWriterEpoch 最新的日志文件对应的编号，会每次在写新的 segment，即 startLogSegment RPC 调用时，会记录或者更新AcceptedInEpoch 上次恢复接受的提案编号，在 accept 阶段持久化 ，什么时候 AcceptedInEpoch 会大于 LastWriterEpoch?，当在一次 paxos 协议执行到 accept 都成功，执行恢复前假设 epoch 是 1， lastWriterEpoch 也是 1，则当前的 epoch 是 2（ newEpoch）但是在最后 finalize 时，在发给最后一个 journal node 时 ActiveNam

8、enode 又 crash 了，这时这个没有收到 finalize 请求的，他的 AcceptedInEpoch 是 2，他的 lastWriterEpoch 还是 1，因为还没有 stargLogSegment，所以还是 1，这种情况下下次再执行 paxos 恢复时，应该恢复 AcceptedInEpoch 对应的 segemnt，这也是在 2 段提交 (2PC) 在 commit 阶段出现故障时，保障一致性的一种容错方式，值得借鉴。3.2 AccepteRecovery根据 PrepareRecovery 选择的结果根据一个算法，选中一个 segment，给所有的journal 发送 accept 请求，告诉他们都要和指定的 segment 达到一致，怎么样达成一致，下面会分析到。PrepareRecover 对应 Paxos 的第一阶段，AccepteRecover 对应第二阶段在分析具体的 2PC 实现之前，先上个图，了解下大概流程光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/上图主要包含的流程总结如下Prepare RecoveryPrepareRecoverRequestprepareResponsecheckRequest 并选择一个 segment 来做为同步源Accept Recovery客户端发起 AcceptRecoveryJournal 接受 AcceptRecovery 请求接受请求后的检查 segment 是否包含事务接受请求后的检查上一次 paxos 是否正常完成，这里的检查是判断是否需要去同步数据commit这里分别对每个阶段的主要行为分析如下：PrepareRecoverRequest(P1a)第一阶段，发起提案光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/服务端 Journal(prepareResponse) P1b:checkRequestjournal 在 newEpoch,

《QJM 核心源代码解读 Hadoop namenode 高可用性分析_光环大数据培训》由会员gua****an分享，可在线阅读，更多相关《QJM 核心源代码解读 Hadoop namenode 高可用性分析_光环大数据培训》请在金锄头文库上搜索。