【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上？

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）

周一至周五早8点半！精品技术文章准时送上！

目录

1、前情概要

2、背景引入

3、问题凸现

4、Hadoop的优化方案

1、前情概要

这篇文章给你们聊聊Hadoop在部署了大规模的集群场景下，大量客户端并发写数据的时候，文件契约监控算法的性能优化。看懂这篇文章须要一些Hadoop的基础知识背景，还不太了解的兄弟，能够先看看以前的文章：兄弟，用大白话告诉你小白都能看懂的Hadoop架构原理。

2、背景引入

先给你们引入一个小的背景，假如多个客户端同时要并发的写Hadoop HDFS上的一个文件，你们以为这个事儿能成吗？

明显不能够接受啊，兄弟们，HDFS上的文件是不容许并发写的，好比并发的追加一些数据什么的。因此说，HDFS里有一个机制，叫作文件契约机制。

也就是说，同一时间只能有一个客户端获取NameNode上面一个文件的契约，而后才能够写入数据。此时若是其余客户端尝试获取文件契约的时候，就获取不到，只能干等着。经过这个机制，就能够保证同一时间只有一个客户端在写一个文件。

在获取到了文件契约以后，在写文件的过程期间，那个客户端须要开启一个线程，不停的发送请求给NameNode进行文件续约，告诉NameNode：大哥，我还在写文件啊，你给我一直保留那个契约好吗？而NameNode内部有一个专门的后台线程，负责监控各个契约的续约时间。若是某个契约很长时间没续约了，此时就自动过时掉这个契约，让别的客户端来写。

说了这么多，老规矩，给你们来一张图，直观的感觉一下整个过程。

3、问题凸现

好，那么如今问题来了，假如咱们有一个大规模部署的Hadoop集群，同时存在的客户端可能多达成千上万个。此时NameNode内部维护的那个文件契约列表会很是很是的大，而监控契约的后台线程又须要频繁的每隔一段时间就检查一下全部的契约是否过时。

好比，每隔几秒钟就遍历大量的契约，那么势必形成性能不佳，因此说这种契约监控机制明显是不适合大规模部署的hadoop集群的。

4、Hadoop的优化方案

那么Hadoop是如何对文件契约监控算法进行优化的呢？我们来一步一步的看一下他的实现逻辑。首先，咱们一块儿来看看下面这张手绘图：

其实奥秘十分的简单，每次一个客户端发送续约请求以后，就设置这个契约的最近一次续约时间。而后，基于一个TreeSet数据结构来根据最近一次续约时间对契约进行排序，每次都把续约时间最老的契约排在最前头，这个排序后的契约数据结构十分的重要。

TreeSet是一种可排序的数据结构，他底层基于TreeMap来实现。TreeMap底层则基于红黑树来实现，能够保证元素没有重复，同时还能按照咱们本身定义的排序规则在你每次插入一个元素的时候来进行自定义的排序。因此这里咱们的排序规则：就是按照契约的最近一次续约时间来排序。

其实这个优化就是如此的简单，就是维护这么一个排序数据结构而已。咱们如今来看一下Hadoop中的契约监控的源码实现：

每次检查契约是否过时的时候，你不要遍历成千上万的契约，那样遍历效率固然会很低下。咱们彻底能够就从TreeSet中获取续约时间最老的那个契约，假如说连最近一次续约时间最老的那个契约都还没过时，那么就不用继续检查了啊！这说明续约时间更近的那些契约绝对不会过时！

举个例子：续约时间最老的那个契约，最近一次续约的时间是10分钟之前，可是咱们判断契约过时的限制是超过15分钟不续约就过时那个契约。这个时候，连10分钟之前续约的契约都没有过时，那么那些8分钟之前，5分钟之前续约的契约，确定也不会过时啊！

这个机制的优化对性能的提高是至关有帮助的，由于正常来讲，过时的契约确定仍是占少数，因此压根儿不用每次都遍历全部的契约来检查是否过时。咱们只须要检查续约时间最旧的那几个契约就能够了，若是一个契约过时了，那么就删掉那个契约，而后再检查第二旧的契约好了。以此类推。

经过这个TreeSet排序 + 优先检查最旧契约的机制，有效的将大规模集群下的契约监控机制的性能提高至少10倍以上，这种思想是很是值得咱们学习和借鉴的。

给你们稍微引伸一下，在Spring Cloud微服务架构中，Eureka做为注册中心其实也有续约检查的机制，跟Hadoop是相似的（若是想了解Eureka注册中心相关技术的朋友，建议看一下：《拜托！面试请不要再问我Spring Cloud底层原理！》）。可是在Eureka中就没有实现相似的续约优化机制，而是暴力的每一轮都遍历全部的服务实例的续约时间。

若是你面对的是一个大规模部署的微服务系统呢，状况就不妙了！

部署了几十万台机器的大规模系统，有几十万个服务实例的续约信息驻留在Eureka的内存中，难道每隔几秒钟都要遍历几十万个服务实例的续约信息吗？

最后给你们提一句，优秀的开源项目，蕴含着不少优秀的设计思想。多看各类优秀开源项目的源码，是短期内快速、大幅度提高一我的的技术功底和技术水平的方式，你们不妨尝试一下。

END

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列

文章正在路上,欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授

推荐阅读：

一、拜托！面试请不要再问我Spring Cloud底层原理

二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

四、微服务架构如何保障双11狂欢下的99.99%高可用

五、兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理

六、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

七、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

八、拜托，面试请不要再问我TCC分布式事务的实现原理坑爹呀！

九、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？

十、拜托，面试请不要再问我Redis分布式锁的实现原理！