作者介绍:简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
中间件,我给它的定义就是为了实现某系业务功能依赖的软件,包括如下部分:
Web服务器
代理服务器
ZooKeeper
Kafka
RabbitMQ
Hadoop HDFS(本章节)
前面3个小节,我们介绍了单机情况下的HDFS的3个组件,其中nn和dn无论单机还是集群都是需要的,而2nn则只在单机下才有用,后面几个我们将介绍高可用集群模式涉及到的几个组件:JournalNode,ZKFailoverController(ZKFC) ,本小节介绍:JournalNode。
JournalNode 是 Hadoop HDFS 中用于实现 NameNode 高可用(High Availability, HA)的核心组件,主要作用是在 Active 和 Standby 两个 NameNode 之间同步元数据变更,确保集群在主 NameNode 故障时,备用节点能快速切换并恢复服务。其设计聚焦于数据一致性、高可靠性与低延迟,以下从核心功能、工作机制、部署架构及关键特性展开详解。
一、核心功能
**元数据变更日志(EditLog)的共享存储:**在非 HA 架构中,NameNode 的元数据变更日志(EditLog)仅存储在本地磁盘,若主节点故障,未同步的日志会导致数据丢失。JournalNode 则作为分布式日志存储服务,接收 Active NameNode 写入的 EditLog,并为 Standby NameNode 提供日志读取接口,实现两者的元数据实时同步:
-
Active NameNode 每次修改元数据(如创建文件、删除目录)后,会将变更记录写入本地 EditLog 的同时,同步发送至 JournalNode 集群;
-
Standby NameNode 持续从 JournalNode 读取新的 EditLog,并重放至自身内存中的元数据镜像(FsImage),确保与 Active 节点的元数据状态一致。
分布式一致性校验:JournalNode 集群采用 "多数派协议"(Quorum)保证日志写入的可靠性:只有当超过半数((N/2)+1
,N 为 JournalNode 节点数)的节点成功写入 EditLog 后,Active NameNode 才会确认该日志写入成功。这种机制避免了单节点故障导致的日志丢失,同时兼顾写入效率(无需等待所有节点确认)。
二、工作机制
EditLog 的写入流程
当 Active NameNode 产生元数据变更时,与 JournalNode 的交互步骤如下:
连接建立:Active NameNode 与所有 JournalNode 建立持久化 TCP 连接,通过 RPC 协议通信;
日志提交:将 EditLog 条目封装为事务(Transaction),按顺序发送至 JournalNode 集群;
多数派确认:每个 JournalNode 接收事务后,先写入本地磁盘的日志文件(路径由 dfs.journalnode.edits.dir
配置),再返回确认信息。Active NameNode 收到超过半数节点的确认后,标记该事务为 "已提交",并更新自身的日志序列号(EditLog Sequence Number);
本地同步:同时将事务写入本地 EditLog 文件(作为备份,避免 JournalNode 集群临时不可用时的日志丢失)。

Standby NameNode 的日志同步
Standby NameNode 通过以下方式保持与 Active 节点的一致性:
-
定期向 JournalNode 发起请求,获取最新的 EditLog 事务(基于自身已同步的最大序列号);
-
将新事务逐条重放至内存中的 FsImage,更新元数据状态;
-
当 Active 节点故障时,Standby 节点已拥有最新的元数据(仅差最后几秒可能未同步的事务,可通过 JournalNode 补全),因此能快速切换为 Active 状态
故障检测与自动恢复
-
JournalNode 定期向 NameNode 发送心跳(默认 5 秒一次),报告自身状态;
-
若某个 JournalNode 故障,Active NameNode 会忽略该节点,仅向正常节点提交日志(只要多数节点存活,服务即可继续);
-
故障节点恢复后,会自动从其他 JournalNode 同步缺失的 EditLog 日志,确保集群日志一致性。
总结
JournalNode 是 HDFS 实现高可用的关键组件,其核心价值在于通过分布式日志存储与一致性协议,解决了 NameNode 元数据同步的难题。在 HA 架构中,它既是 Active 节点的日志备份者,也是 Standby 节点的状态同步源,确保集群在主节点故障时能无缝切换,大幅提升了 HDFS 的可用性。部署时需注意节点数量(奇数)、硬件性能(低延迟磁盘与网络)及容错配置,以充分发挥其在高可用集群中的核心作用。
运维小路
一个不会开发的运维!一个要学开发的运维!一个学不会开发的运维!欢迎大家骚扰的运维!
关注微信公众号《运维小路》获取更多内容。