今天看到了Google实验室的一篇学术论文:MapReduce: Simpli ed Data Processing on Large Clusters。刚看到时很兴奋,感觉其中的网格计算的思想很是优秀。但兴奋过后,发现其原理其实比较简单,而且好像只适合用于一些需要进行非实时的大规模计算的场合,如搜索引擎的统计工作,对大部分开发任务来说,并无多大借鉴意义。
但MapReduce的这种思想,倒与我之前曾经的一个想法,有些不谋而合:)
我目前参与的一个项目,会在每晚进行整个系统的每日构建,现在由于现在代码量过大,而且由于部分工程组织不合理,导致编译时间过长,每次完整构建的时间超过了12小时。所以一般两天才完成一次构建,而工作中按需要随时构建简直就是一场灾难。为解决这个问题,曾构想过如下一个网格计算环境(受Google File System的启发):
网格计算框架:
一个网格管理节点,提供如下服务:
接收网格计算任务(包含一个工作者程序和一个管理者程序,以及相关数据)
将计算任务的工作者程序分发给多个网格节点
启动计算任务的管理者程序
维护网格节点的加入和退出,将退出节点上的任务重新分配到其他节点上
多个网格节点,每个网格节点,提供如下服务:
接收节点管理器分发的工作者程序
接收节点管理器的调度,并调用工作者程序进行工作
监视并报告工作者程序的工作情况
那么,针对这个每日编译的任务,除了以上框架外,还需要如下两个处理程序。
工作者程序:
下载源代码包
向管理者获取需要编译的模块(源代码包中的路径)
解压、进入指定模块所在目录、make
打包编译结果(一些obj文件)
上传编译结果
管理者程序:
从CVS中下载源代码并打包,以供工作者下载
将整个系统按模块划分的方式分配给多个工作者
接收和合并各工作者编译的结果
链接各工作者编译的结果
再次编译并链接整个系统(增量方式)
打包最终编译结果,发布
在这里记下来,也许哪天可以实现一个看看。