首页 > 编程知识 正文

java经典算法(java计算公式编程)

时间:2023-05-03 17:54:24 阅读:73792 作者:4569

原标题: Java开发也需要了解算法吗?

许多Java开发同学经常怀疑,做Java开发是否也需要理解算法? 谈谈这个问题吧。

其实一旦开发出非常复杂、具有挑战性的大规模系统,系统必然会用到算法。 同样,如果能够合理地优化算法,也可以将系统性能提高几十倍

因为没有根据,所以用实际情况说明。 在Hadoop部署大型集群的场景中,让我们来看看文件合同监视算法在多个客户端同时写入数据时的性能优化。

选择此选项作为示例,因为Hadoop是世界上最复杂的基于Java的分布式系统。 该算法的优化可以提高系统的性能,可见Java程序员们开发系统时算法很重要。

首先阅读这篇文章需要Hadoop的基础知识背景,了解其结构原理

首先,让我介绍一下小背景。 如果多个客户端同时写Hadoop HDFS上的一个文件,你认为能做到吗?

显然不能接受啊。 兄弟们,HDFS上的文件不允许同时写入。 例如,通过同时写入添加数据。

也就是说,HDFS有一种叫做文件合同机制的机制

这意味着每次只有一个客户端可以在写入数据之前获取NameNode上一个文件的合同。 在这种情况下,如果其他客户端试图获取文件的合同,则无法获取,只能等待。 这种机制确保了同一时间只有一个客户端写一个文件。

获得文件合同后,在撰写文件时,该客户端必须打开线程请求NameNode更新文件。 NameNode :哥哥,我还在写文件。 你能一直给我留下那个合同吗?

在NameNode内部,有一个专用的后台线程来监视每个合同的更新时间,如果一个合同长时间没有更新,该合同就会自动过期,让另一个客户端写。

请看下图:

那么,发生了问题。 如果hadoop群集中有大规模部署的客户端,同时存在的客户端可能多达数千个,则NameNode内部维护的文件合同列表将非常大。

监控合同的后台线程必须每隔一段时间检查所有合同是否过期。 例如,每几秒遍历大量合同会降低性能。 我们发现,这种合同监控机制不适用于大规模部署的hadoop群集。

Hadoop是如何优化文件合同监控算法的呢? 让我们一步一步地看看他的实现逻辑。 先一起看看下图吧。

奥秘非常简单,每当一个客户端发送更新请求时,它都会设置该合同的最新更新时间。 然后根据TreeSet数据结构,根据最新的更新时间对合同进行排序。 每次都以更新时间最早的合同为开头。 这个排序的合同数据结构非常重要。

TreeSet是一种可排序的数据结构,其基础是基于TreeMap实现的,而TreeMap基础是基于红黑树实现的。 这样,在确保元素不重复的同时,可以根据我们定义的排序规则在每次插入元素时进行自定义排序。

所以,这里我们的排名规则只要根据合同最近的更新时间排名就可以了。

其实这个优化这么简单,只是维持这样的排序数据结构。 看看Hadoop合同监控的源代码实现:

Lease leaseToCheck=null; try { lease to check=sorted leases.first (; }catch(nosuchelementexceptione ) while ) leasetocheck!=null(if (! leaseToCheck.expiredHardLimit () { break; }

怎么样? 写Hadoop和Spring Cloud等优秀的开源项目的选择,是不是让人不得不佩服他的棒球技术水平呢? 大量阅读各种复杂优秀的开源项目的源代码,确实可以快速提高人的体系结构能力、技术能力和技术视野。 这也是我平时花很多时间在做的事情。

不要每次检查合同是否到期时都遍历成千上万的合同。 那么遍历效率很低,可以从TreeSet获得更新时间最久的合同

如果说连最近更新时间最早的合同都还没到期,那就没必要继续检查了。 因为更新时间更近的合同表示绝对不会失效!

例如,对于更新时间最早的合同,我们认为最近更新的时间是10分钟前,但合同有效期限制必须超过15分钟才能更新。

这意味着,10分钟前更新的合同也没有失效,所以8分钟前、5分钟前更新的合同也一定不会失效

这个机制对性能的提高相当有帮助。 通常,过期的合同一定还是少数,所以不需要每次都检查所有合同来检查是否过期。 只要检查一下更新时间最久的合同就可以了。

一份合同到期后,删除该合同,检查第二份旧合同。 接下来类推。

通过这个TreeSet排行榜中优先检查最旧合同的机制,有效提高大型集群中合同监视机构的性能至少10倍以上,这一思想在我们自己进行系统设计时非常有价值

学习和借鉴的。

给大家引申一下,在Spring Cloud微服务架构中,Eureka作为注册中心其实也有续约检查的机制,跟Hadoop是类似的

但是在Eureka中就没有实现类似的续约优化机制,而是暴力的每一轮都遍历所有的服务实例的续约时间。

假如你是一个大规模部署的微服务系统呢?比如部署了几十万台机器的大规模系统,有几十万个服务实例的续约信息驻留在Eureka的内存中,你难道要每隔几秒钟遍历一下几十万个服务实例的续约信息吗?

相信看到这里,本文开头提出的Java工程师是否也要懂一些算法,大家心里也有答案了吧!返回搜狐,查看更多

责任编辑:

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。