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

这段时间其实一直在思考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，进行学习和思考的一点想法，写得不好，欢迎大家拍砖.