关于分布式流水作业架构的一点浅见(领导者压力和瓶颈的解决方法和思路)
这段时间其实一直在思考Hadoop的东西，主要是我准备用Dotnet来模拟玩一下，这两天刚好看到 这篇文章，看来对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) 各个劳动者接到项目经理的任务分配后，会执行具体的生产任务，并定期将情况汇报给项目经理，任务完成后也会将结果汇报给项目经理;