`
xpp02
  • 浏览: 1049090 次
社区版块
存档分类
最新评论

关于分布式流水作业架构的一点浅见(领导者压力和瓶颈的解决方法和思路)

阅读更多

 

        这段时间其实一直在思考Hadoop的东西,主要是我准备用Dotnet来模拟玩一下,这两天刚好看到 http://blog.csdn.net/cenwenchu79/article/details/7206804 这篇文章,看来对hadoop的架构有看法的不止我一个,当然,别人都是牛人,有牛人敢怀疑,我也跟着说点看法。
首先,坦率的讲,我没有用过hadoop,我只是了解过其机制,根据上面那位牛人的看法,hadoop的master会成为瓶颈,因为其担当的Reducer职责,就是最后归并结果。因为我没有实际用过hadoop,我没有发现这个问题,只是我在准备模拟hadoop的思考过程中,我觉得master的职责应该比较单一,如果master担当的任务分割职责(比如大文件切割)计算量和数据流量比较大的话,会很容易成为分布式计算系统的性能瓶颈。基于现实企业运作模式的类比思考,分布式流水作业集群(包括hadoop集群)其实就相当于一家代加工企业,具有销售,生产,仓储,管理,人力资源等角色(真的企业还要有财务等,但在这里就不需要了):
        销售负责订单接受和任务交付,生产负责具体的计算(Map,Reduce等,不局限于这些,只要符合流水生产特征即可)。仓储负责原料和成品的存储,就是文件或数据库系统。管理者负责居中协调,为了不出现多头领导的问题,管理角色分化为两种角色,全局管理者(全局领导者 )和项目经理(事务领导者,每个订单相当于一个项目),全局管理者(Master)就是公司总经理,负责指挥和协调,只能有一个,项目经理负责具体事务(按订单)的管理,可以有多个,Master除了协调指挥外,当然还担当着一个人力资源管理的角色,人力资源当然就需要管理生产者,项目经理,仓储等角色的数量和状态。而仓储角色,则可以由专门的文件系统来担当,负责原料,半成品,成品的存储。目前的hadoop从我得到的信息来讲,其Master一个人担当了销售,管理,生产者和人力资源四种角色,责任太重,容易成为瓶颈也是自然的事情。

我们知道,在企业管理中,多头领导和责任重叠都是要极力避免的,当然,如果完全按照责任单一原则区分,在计算系统实现上一是没有必要,二也会增加复杂度,得不偿失。计算机诞生于人类生产生活,其实很多做法也都来自于现实生产生活中。人类的生产生活天生就是分布式和并发的。在现实中流水线生产不失为一种高效的生产方式,hadoop中的mp只是一种简单的流水作业模式。当然,计算系统中,没有现实生产生活这么复杂,也没有必要完全模拟现实(同时也很难做到)。回来,我们分析一下hadoop的master的职责,多头领导的问题当然不存在,人力资源角色因为要协调,所以是必需的(而且该信息对于master来说非常关键,工作量不算很大,因此独立出一个角色来管理没有必要),但部分生产者和项目管理职责则完全没有必要,何况这两种角色都是比较消耗资源的。何况全局管理者由于其特殊性,无法实现均衡负载,而且必须是固定的(因为是所有其他角色的中介者,必须是固定的,否则通信和临时选举成本太高)。 但在这种分布式计算系统中,最终结果的合并由任务管理者来完成是个非常好的选择(专门指定这种合并角色不是不可以,但会增加计算系统的复杂度和实现、管理难度)  ,由于这种合并基本上都是按项目(订单任务)来的,因此交由项目经理角色完成比较好。业务的角色可以单独设置,也可以由Master担当,不过我觉得单独设置会比较好,其实Master不必对外,由业务对外会比较好。

这种计算作业系统的整体业务逻辑及流程如下:

A)除Master外的其它角色都会通过心跳服务,向Master注册和更新自己的状态(其实Master崩溃的情况下,也可以通过这种机制做Master恢复(部分),只是机制比较复杂点);
B)业务在接到订单(加工任务)后会先把订单交给Master,业务并不需要保存订单信息,这也决定了其可以实现负载均衡,是客户与计算系统之间的交互中介;
C)Master根据劳动者状态,分配加工任务给某个劳动者,并指定其为项目经理,具体的任务管理(项目管理)由项目经理去完成;
D)项目经理接到任务后对任务进行必要的拆分,并向Master申请劳动者资源并分配任务给这些资源,同时进行项目管理(项目情况汇报,项目成员工作中进度了解等);
     项目经理在成员出现问题时采用的策略跟该职责在原来Master中实现一样,只不过是由项目经理完成。当然,Master如果发现项目经理挂了,也可以基于同样的策略,再任命一个项目经理重新开始任务。(后面有专文来探讨这个问题的解决)
E) 各个劳动者接到项目经理的任务分配后,会执行具体的生产任务,并定期将情况汇报给项目经理,任务完成后也会将结果汇报给项目经理;
F)项目经理如果发现有成员任务没完成,而且失去联系,则将该子任务重新指定劳动者去完成(可以内部协调,也可以向master申请新的资源);(为了提高效率,项目经理可以在劳动者完成任务后即报告给master,释放控制权,但保留联系,只有在任务清场后才彻底脱离关系)
G)项目经理在项目完成后,会将结果合并,并将完成信息报告给Master,Master接到报告后会通知业务去进行订单交互;
H)具体的交付由客户、业务和项目经理一起完成,当然会将交互结果汇报给Master.
I)订单交付完成后,Master指示项目经理清场,并将项目经理解职(成员清场可以在项目经理确定任务完成时就进行)。
J)中途出现问题可以从C和E重新开始.

从上面的逻辑和过程可以看出,Master的职责比原来要单一很多,因为大的通信和计算部分都是由可以负载和替换的具体劳动者完成,所以Master很难会成为瓶颈。这也是为什么管理非常好的企业,总经理都比较闲的原因。但这种方式的劣势是增加了设计和实现的难度,同时如果因为项目经理挂掉,重新启动项目的成本也会比较高(也可以采用一些方法减少些成本)。当然,任何事情都不会是完美的,就看怎么取舍了。

上面那位牛人提出的Master横向扩展,不是不可以,但实现起来会很困难,因为如果要保证可靠性和一致性,最终一定有一个地方需要统一,只能由一个点来担当这种统一的职责(但可以有对等的备份),否则像Google这样的大牛公司的GFS实现中的Master也肯定不会采用领导者选举算法来保证某一时刻只能有一个领导者的办法。因此我觉得,要减轻领导者压力,只能采用剥离其担负的非关键性业务或者功能来实现。提高领导力,也只能升级设备。

 

另外,由于原来master担负的任务分割结果可能会重用,在这种模式下,需要增加一个指示来指示项目经理如何管理任务分割结果(比如大文件分割等).当然,细节需要处理的地方还很多,套用一句话:思路决定高度,细节决定结果。   好的架构也必须契合好的管理,好多东西都是相互借鉴和渗透的,高层次上大家也都是统一的,随着层次越高,统一性越强,最终上升到的高度就是哲学。

我目前在考虑的就是这种扁平化下的项目经理负责制,仿照现实生产活动中的敏捷制造方式。当然,这些也算是这段时间准备实现自己的mp,进行学习和思考的一点想法,写得不好,欢迎大家拍砖.

更多信息请查看 java进阶网 http://www.javady.com/index.php/category/thread

分享到:
评论

相关推荐

    人人都是架构师+分布式系统架构落地与瓶颈突破+高清完整版

    人人都是架构师+分布式系统架构落地与瓶颈突破+高清完整版 本书并没有过多渲染系统架构的理论知识,而是切切实实站在开发一线角度,为各位读者诠释 了大型网站在架构演变过程中出现 系列技术难题时的解决方案。本书...

    分布式架构

    分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构...

    分布式系统架构落地与瓶颈突破

    高翔龙,杭州云集微店架构师,基础架构组负责人,负责基础技术平台的架构设计和中间件研发等工作,技术书籍《Java...相信阅读《人人都是架构师:分布式系统架构落地与瓶颈突破》你将会有知其然和知其所以然的畅快感。

    SpringBoot面向线上支付平台的分布式微服务架构研究

    SpringBoot面向线上支付平台的分布式微服务架构研究 SpringBoot面向线上支付平台的分布式微服务架构研究 SpringBoot面向线上支付平台的分布式微服务架构研究 SpringBoot面向线上支付平台的分布式微服务架构研究 ...

    《信息技术 区块链和分布式记账技术 参考架构》(征求意见稿).pdf

    《信息技术 区块链和分布式记账技术 参考架构》(征求意见稿)是我国提出的一项关于区块链和分布式记账技术的国家标准草案,此标准旨在提供一个统一的参考架构,指导区块链及分布式记账技术的应用和发展。...

    人人都是架构师+分布式系统架构落地与瓶颈突破.pdf

    《人人都是架构师:分布式系统架构落地与瓶颈突破》是一本深入探讨IT系统架构的书籍,旨在帮助读者理解和掌握分布式系统的设计与优化。书中详细阐述了如何从传统的单体架构过渡到分布式架构,并解决在这一过程中可能...

    [网盘]大型分布式网站架构设计与实践.pdf

    大型分布式网站架构设计与实践.pdf <br/>《大型...《大型分布式网站架构设计与实践》既可供初学者学习,帮助读者了解大型分布式网站的架构,以及解决问题的思路和方法,也可供业界同行参考,给日常工作带来启发。

    分布式系统架构设计思路

    分布式系统架构设计是构建和维护大型、高性能、可扩展和高可用性的互联网服务的关键。分布式系统通过把工作负载分散到多个服务器上,提高了系统的整体处理能力,并能够应对高并发请求。在设计分布式系统时,负载均衡...

    高能物理分布式数据获取架构的设计与实现.pdf

    随着高能物理实验规模的不断扩展和数据量的持续增长,这种架构的设计思路和技术实现将显得越发重要。未来的研究和开发可以围绕进一步提高数据处理的效率、加强系统的稳定性以及扩展系统的适用性等方面进行深入探索。

    大型分布式网站架构设计与实践.带目录书签.完整版 陈康贤

    《大型分布式网站架构设计与实践》主要介绍了大型...《大型分布式网站架构设计与实践》既可供初学者学习,帮助读者了解大型分布式网站的架构,以及解决问题的思路和方法,也可供业界同行参考,给日常工作带来启发。

    大型分布式网站架构设计与实践

    《大型分布式网站架构设计与实践》主要介绍了大型...《大型分布式网站架构设计与实践》既可供初学者学习,帮助读者了解大型分布式网站的架构,以及解决问题的思路和方法,也可供业界同行参考,给日常工作带来启发。

    分布式计算机软件架构现状及未来发展趋势研究.pdf

    云计算架构是随着云服务的兴起而发展起来的一种新型架构模式,它是为了解决大量用户并发访问、数据的海量存储和处理需求而设计的。云计算架构通过提供类似“软件即服务”(SaaS)的模式,使得用户能够利用互联网按需...

    分布式集群系统架构设计及应用部署.pdf

    分布式集群系统架构设计及应用部署是指在高并发访问量和海量数据环境下,通过部署分布式集群环境系统来解决由于瞬间并发访问量过大造成网站崩溃、服务暂停的问题。该系统架构设计采用了分布式模式,使用 Vue 和 ...

    大型分布式网站架构设计与实践.带目录书签.完整版.rar

    《大型分布式网站架构设计与实践》既可供初学者学习,帮助读者了解大型分布式网站的架构,以及解决问题的思路和方法,也可供业界同行参考,给日常工作带来启发。 作者简介 陈康贤,淘宝花名龙隆,淘宝技术部研发...

    java分布式系统架构问题解决与瓶颈突破

    在《Java分布式系统架构问题解决与瓶颈突破》一书中,作者深入探讨了互联网环境中大型网站架构的演变历程,以及在这一过程中所面临的关键技术挑战及其解决方案。这本书是为那些希望成为架构师或已经在该领域工作的...

    分布式文件系统架构

    分布式文件系统架构

    大型分布式网站架构设计与实践.带目录书签.完整版.pdf

    大型分布式网站架构设计与实践 分布式规模服务下的...《大型分布式网站架构设计与实践》既可供初学者学习,帮助读者了解大型分布式网站的架构,以及解决问题的思路和方法,也可供业界同行参考,给日常工作带来启发。

Global site tag (gtag.js) - Google Analytics