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

光环大数据--大数据培训知名品牌 QJM 核心源代码解读 Hadoop namenode 高可用性分析_光环大数据培训 HDFS namenode 在接受写操作时会记录日志，最早 HDFS 日志写本地，每次重启或出 现故障后重启，通过本地镜像文件＋操作日志，就能还原到宕机之前的状态，不会出现数据 不一致。如果要做高可用 (HA)，日志写在单个机器上，这个机器磁盘出现问题，重启就恢 复不了，导致数据不一致，出现的现象就是新建的文件不存在，删除成功的还在等诡异现象。 这是分布式存储系统不能容忍的。 在单机系统上是通过 WAL （write ahead log ）日志来保证出问题后可恢复，在 HDFS 上 对应的就是操作日志（EditLog），用于记录每次操作的行为描述。这里我们简单介绍下 editlog 的格式。 文件格式 编辑中的日志 edits_inprogress_txid，也就是后文提到的 segment ，txid 代表该日 志文件的第一个事务 ID Finalized 日志即一致不再更改的日志文件 edits_fristTxit_endTxid 内容格式 文件头：有版本号 ＋ 一个事务头标识 文件内容 1 操作类型 － 占1 个字节 2 日志长度 － 占4 个字节 光环大数据 光环大数据--大数据培训知名品牌 3 事务txid － 占8 个字节 4 具体内容 5 checksum － 4 个字节 文件结尾：一位事务标识 注意之前没有 journal 分布式日志时，每次 flush 日志时在该段日志后面加一个标识 INVALID_TXID，在下次 flush 时会覆盖该标识，但目前的版本去掉了这个标识 通过 editlog 能做到单机版系统的可靠性，但是在分布式环境下，要保证namenode 的 高可用，至少需要两台 namemode。要做到高可用，高可靠，首先就是保证 HDFS 的操作 日志 (EditLog) 有副本。但有了副本就引入了新的问题，多个副本之间的一致性怎么保证， 这是分布式存储必须解决的问题。为此 Clouder 公司开发了 QJM（Quorum Journal Manager ） 来解决这个问题。 Journal Node 集群 Journal node 是根据 paxos 思想来设计的，只有写到一半以上返回成功，就算本次写成 功。所以 journal 需要部署 3 台组成一个集群，核心思想是过半 Quorum，异步写到多个 Journal Node 。 写日志过程 editlog 写入到多个 node 的过程简单描述如下： ActiveNamenode 写日志到 Journal Node ，采用 RPC 长连接 光环大数据 光环大数据--大数据培训知名品牌 StandbyNamenode 同步已经 Finally 日志生成镜像文件, 以及 Journal Node 直接同 步数据，采用 HTTP ActiveNamenode 每接收到事务请求时，都会先写日志，这个写日志的过程，网上有好 多好的文章做分析，这里只是大概说下值得我们学习的地方以及一些好的设计思想。 1 批量刷磁盘 这个应该说是写日志的通用做法，如果每来一条日志都刷磁盘，效率很低，如果批量刷 盘，就能合并很多小 IO （类似MySQL 的 group commit ） 2 双缓冲区切换 bufCurr