一、概要
这篇文章,给大家聊聊分布式文件系统hdfs在大量客户端并发写数据时,如何进行性能优化?
二、背景引入
先引入一个小的背景,假如多个客户端同时要并发的写hadoop hdfs上的一个文件,这个事儿能成吗?
明显不可以接受啊,因为hdfs上的文件是不允许并发写的,比如并发的追加一些数据什么。
所以hdfs里有一个机制,叫做文件契约机制。
也就是说,同一时间只能有一个客户端获取namenode上面一个文件的契约,然后才可以写入数据。
此时如果其他客户端尝试获取文件契约的时候,就获取不到,只能干等着。
通过这个机制,可以保证同一时间只有一个客户端在写一个文件。
在获取到了文件契约之后,在写文件的过程期间,那个客户端需要开启一个线程,不停的发送请求给namenode进行文件续约,告诉namenode:
namenode大哥,我还在写文件啊,你给我一直保留那个契约好吗?而namenode内部有一个专门的后台线程,负责监控各个契约的续约时间。
如果某个契约很长时间没续约了,此时就自动过期掉这个契约,让别的客户端来写。
说了这么多,老规矩,给大家来一张图,直观的感受一下整个过程。
这个机制的优化对性能的提升是相当有帮助的,因为正常来说,过期的契约肯定还是占少数,所以压根儿不用每次都遍历所有的契约来检查是否过期。
我们只需要检查续约时间最旧的那几个契约就可以了,如果一个契约过期了,那么就删掉那个契约,然后再检查第二旧的契约好了。以此类推。
通过这个treeset排序 + 优先检查最旧契约的机制,有效的将大规模集群下的契约监控机制的性能提升至少10倍以上,这种思想是非常值得我们学习和借鉴的。
给大家稍微引申一下,在spring cloud微服务架构中,eureka作为注册中心其实也有续约检查的机制,跟hadoop是类似的。
但是在eureka中就没有实现类似的续约优化机制,而是暴力的每一轮都遍历所有的服务实例的续约时间。
如果你面对的是一个大规模部署的微服务系统呢,情况就不妙了!
部署了几十万台机器的大规模系统,有几十万个服务实例的续约信息驻留在eureka的内存中,难道每隔几秒钟都要遍历几十万个服务实例的续约信息吗?
最后给大家提一句,优秀的开源项目,蕴含着很多优秀的设计思想。多看各种优秀开源项目的源码,是短时间内快速、大幅度提升一个人的技术功底和技术水平的方式,大家不妨尝试一下。
2019年,中小企业网站建设需求变化趋势网站建设完一定要安排专人来维护你网站在百度经历了什么为什么迟迟没有排名?企业建网站是选择云服务器还是云虚拟主机?网站设计建设应遵循哪些原则?网站优化推广揭秘百度优化技巧时间的神秘面纱电商企业该如何选择香港CN2服务器租用郑州网站建设需要多少钱?