HDFS 读写分离（总体架构介绍）

最新推荐文章于 2024-08-01 15:57:06 发布

凡哲_Lucas

最新推荐文章于 2024-08-01 15:57:06 发布

阅读量1.8k

点赞数 2

分类专栏： HDFS

本文链接：https://blog.csdn.net/weixin_35792948/article/details/103058749

版权

本文探讨了HDFS为何需要读写分离，并详细分析了当前的HA架构、全局锁的问题及其对性能的影响。提出了拆分锁粒度和从Standby Namenode进行读取的改善方案，同时详细讲解了一致性读面临的挑战、实现需求和细节，包括新的API `FileSystem.msync()`的功能和优化点。

摘要由CSDN通过智能技术生成

为什么HDFS需要读写分离

当前架构：

目前HDFS在HA模式下的架构图如如下：
在这里插入图片描述

HA同步机制简单介绍：

客户端读写都通过RPC连接Active Namenode进行操作，Standby Namenode不具有读写的功能只负责同步操作记录（Editlog）。Editlog是Active Namenode通过RPC写到由PAXOS协议实现的一组Journalnode，然后Standby Namenode通过HTTP协议去拉Journalnode的Editlog进行同步的。

读写的全局锁

上面介绍了客户端只能通过RPC从Active Namenode，那么Active Namenode既承载了读的压力，又承载了写的压力。感性上我们会觉得它的压力很大，那么我们根据事实进行分析一下。
在这里插入图片描述

如上图所示，Namenode的FSNamesystem类中主要有三块。

INodeMap中存着目录树的映射关系：Id -> INode
BlocksMap中存着块和块位置信息的映射信息。Block -> BlockInfo
DataNode Manager : 用于对DataNode进行管理。
（GSet是一种高效的HashMap实现）

而这三种数据结构都在全局锁读写锁的锁范围内：
全局读写锁类（暂时不对读写锁的进行实现分析，封装了常见的读写锁实现类ReentrantReadWriteLock）：
在这里插入图片描述
虽然写的场景在集群中可能只占10%左右，读的场景占90%左右。但是无论是目录树还是块管理的更新，都在全局锁的写锁范围内，而写锁是排他锁，会对集群的整体读写延迟等性能和集群整体的吞吐量产生较大的影响。所以为了提升读写性能，和集群的吞吐量，社区等对HDFS读写分离展开了讨论和开发。