最近工作中接触到分布式服务器，现针对学到的作简要概述, 分布式服务器之路刚起步。

整体框架

下面结合Hadoop的框架思想与工作中接触到的分布式框架，给出简易分布式服务器框架的设计。整体设计框架如下图所示：

如上图示，可以将整体模块分为5个结构层次，分别为： 客户端层、JobTracker层、TaskTracker层、DBC/CloudC层、以及最后的 DB/Cloud层。

  • 客户端层

该层即为客户端的web访问层，通过http访问JobTracker层。 web与JobTracker的具体协议可以协定，或者RPC/HTTP协议都可以。 客户端的主要完成工作请求、暂停、删除作业；获得作业的运行状态信息等。

  • JobTracker层

该层是整个分布式服务器的核心层。它是整个集群中唯一的全局“管理者”，涉及的功能包括作业管理、状态监控、任务调度等。 总体而言，JobTracker主要包括两个功能：作业的调度与TaskTracker资源的管理。下节将具体讲解简易集群JobTracker的实现原理。

  • TaskTracker层

TaskTracker主要负责任务的执行和任务状态的上报，还有就是分析后结果的入库等等。

  • DBC/CloudC层

DBC为数据库控制模块，CloudC为云存储控制模块。这里通过这两个模块与下面的数据库、云存储交互。控制模块中可以通过缓存机制，连接池机制等减轻直接访问DB/Cloud的压力。

  • DB/Cloud层

DB/Cloud分别为数据库、云存储（可以部署在一台服务器或不同的服务器上） 。为啥要分数据库和云存储呢？ 对于结构化的信息，存储在数据库中比较方便，能够插入、更新、修改（这里的数据库设计的是关系型数据库，而非HBase那种面向列的存储数据库）。云存储则存储的是大的文件信息，这样TaskTracker通过调用CloudC的API，获得资源所在云存储的URL，TaskTracker能够根据URL直接访问云存储。

JobTracker实现细节

JobTracker是整个系统的核心租价，是系统高效运转的关键。其实现框架如下图：

这里，将JobTracker的内部框架分为四个模块，分别是 TaskScheduler（任务调度模块），TaskSelect（任务选择模块），ResourceSelect（资源选择模块，选择哪个TaskTracker执行任务）。私有DB模块（存放任务的数据库）。

  • TaskScheduler模块 该模块负责Job与Task之间的关系维护，负责Job与task的进度管理及更新等工作。这里可以仿照hadoop采用“二层多叉树”方式描述和跟踪每个作业的运行状态（Hadoop采用的“三层多叉树”，多了一层任务运行尝试）。

其中，JobTracker为每个作业创建一个JobInProcess对象以跟踪和监控其运行状态。该对象存在于作业的整个运行过程中。同时，采用分而治之的策略，JobInProcess将每个作业拆分成若干个任务，并为每个任务创建一个TaskInProcess对象以跟踪和监控其运行状态。

该模块还负责task与resource对应关系的管理。即哪个task放到了哪个tasktracker节点执行的。这就涉及到了与TaskSelect、ResourceSelect模块的交互。

从图中可以看到，有私有数据库，这里的目的是将作业的信息、作业运行的当前状态等信息入库，JobTracker单点故障，重启后能够从数据库中读取保存的信息，重新运行任务。Hadoop中采用的日志方式进行任务的恢复，关于adoop的日志恢复，有待研究。这里姑且用任务数据库仿照Hadoop的日志恢复。

  • TaskSelect模块

该模块负责任务切片的选择。 因为客户端的 job是带有优先级的，有些job需要先执行，有些可以延后。 所以这里job切分的task切片都需要存放到TaskSelect模块的队列中，然后该模块选择优先级较高的task返回给TaskScheduler，表示当前可以执行该任务了。

该模块中的优先级可以通过client端用户设定，而且优先级会根据时间长短动态调整。

  • ResourceSelect模块

该模块负责资源的选择。TaskTracker会定时发送心跳包给JobTracker，而发送的心跳包中包括资源使用情况（该节点的cpu利用率，内存利用率等信息你）以及任务运行状态。这些信息都将被保存在ResourceSelect这个模块。

为每个TaskTracker节点创建一个对象（TaskTrackerObj），然后通过心跳来更新TaskTrackerObj中的状态信息。

TaskTracker实现细节

TaskTracker是任务的执行者，主要负责任务的执行和任务状态的上报。该模块的框架图如下所示：

该模块中也有个管理模块TaskManager。该模块的作用相当于任务执行者的管理者。它有权限控制下面的Task（可以拉起、暂停、杀死下面任意一个Task）。它还会收集自身的资源，各个任务的状态等信息上报给JobTracker。 也就是说它是与JobTracker直接交互的。

这里，Task运行后的结果统一经过DBC保存到了DB中， 而Task需要的资源可以通过CloudC，获得资源的URL，然后直接下载到本地或者内存 。

存在问题

与真正的Hadoop设计思想相比较，会发现笔者这里的简易集群确实简单，只是涉及了MapReduce的 master/slave架构，而对另外两个hadoop的精髓——HDFS、HBase则未涉及。只是实现简单的分布式计算，未实现分布式的存储。

该设计也存在单点故障问题， 比如JobTracker的， DBC的，CloudC的单点故障等等。