基于glusterfs和gearman的离线任务运算分布式化方案介绍

web站点服务中，咱们除了存在面向用户的服务功能外，每每也存在大量的后台离线的相关计算任务，如对前端的异步操做数据队列进行按期处理，对数据库中的数据进行汇总挖掘，监控，转储，对中间数据的进一步运算处理等等……一个web服务站点的背后，每每存在大量对应的后端处理任务的功能模块，用于支撑正常的业务功能系统。 

在一个web站点的初始阶段，咱们可能只须要有一台服务器，容纳部署全部的业务功能，包括了面向用户的前端web服务功能，数据存储，后端离线处理业务功能。随着站点的业务功能愈来愈多，用户访问数的增长以及数据量的增加，单台服务器的处理能力每每就面临瓶颈。这个时候简单的处理就是将前端web服务功能，数据库和后端业务模块分开部署在不一样的机器上，可是可能过随着站点规模的逐渐庞大，单个服务器也没法支撑前端web服务，数据库服务或者后端离线业务功能。Web前端服务，数据库服务相对是通用的技术服务，相关业务都大同小异，其分布式化在业界有相对很成熟和典型的架构模式解决方案，可是不一样系统的后端离线业务功能可能千差外别五花八门,不一样开发者开发出来的功能架构也各不相同，本文介绍一种低代价的web站点离线任务分布式改造方案，其使用了glusterfs分布式文件系统以及gearman分布式运算框架。 

咱们知道，相关离线运算要能进行分布式化运算，作到单次执行在任意一台机器上执行均可以，其首先的要求就是程序依赖输入输出数据的非本地，咱们要实现运算的分布式化，就必须实现全部存储数据的中心化存储以及分布式化。 

 

一 存储的中心化和分布式化 

     咱们知道一个web站点的业务功能必然要使用各类数据，须要存放各类数据，基本上是以关系型数据库，nosql数据服务，session数据，cache数据，原始的服务器文件数据存储。对于关系型数据库，nosql数据库，其自己就是中心化的数据存储，其分布式化也有成熟的解决方案,对于站点session，相关cache数据，也有成熟的memcached等利用而进行中心化存储，以及进行分布式的扩展。对于大多数后台离线业务功能来讲，每每是开发人员逐渐开发堆积而来，这些功能程序每每会存在大量对本地文件的直接读写，若是改造使用其余存储方式，工做量巨大并且风险大，这些数据的中心化存储改造每每成了解决数据存储中心化的聚焦点，并且所幸，业界有大量成熟的分布式文件存储系统，可以帮咱们解决本地文件存储的中心化和分布式化存储。咱们介绍一种使用glusterfs进行对本地文件存储的分布式化处理方案。 

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不必定直接链接在本地节点上，而是经过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模 式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性容许一些系统扮演客户机和服务器的双重角色。例如，用户能够“发表”一个容许其余客 户机访问的目录，一旦被访问，这个目录对客户机来讲就象使用本地驱动器同样。 

GlusterFS是 一个高层次的分布式文件系统解决方案。经过增长一个逻辑层，对上层使用者掩盖了下面的实现，使用者不用了解也不需知道，文件的存储形式、分布。 

内部实现是整合了许多存储块（server） 经过Infiniband RDMA或者 Tcp/Ip方 式互联的一个并行的网络文件系统，这样的许多存储块能够经过许多廉价的x86主 机，经过网络搭建起来。 

其相对于传统NAS 、SAN、Raid的 优势就是： 

1.容量能够按比例的扩展，且性能却不会所以而降 低。 

    2.廉价且使用简单，彻底抽象在已有的文件系统之上。 

   3.扩展和容错设计的比较合理，复杂度较低。扩展使用translator方 式，扩展调度使用scheduling接口，容错交给了本地的文件系统来处理。 

   4.适应性强，部署方便，对环境依赖低，使用，调试和维护便利。 

支持主流的linux系统发行版，包括 fc，ubuntu，debian，suse等， 并已有若干成功应用。 

对于一个站点的后端离线功能的文件存储来讲，咱们既但愿能将这些文件数据存储中心化，又但愿可以兼容已有的代码，基于这两种考虑，咱们能够按照以下的方案图来进行本地文件迁移到glusterfs文件系统: 

 

这样，咱们就即能实现文件存储的分布式化，又能兼容已有业务程序，作到无缝迁移。 

二运算任务分布式化 

    当咱们的业务程序依赖的存储和数据都中心化，而不依赖于本地存储的时候，咱们的运算任务就能够在任何一台部署环境和代码运算服务器上运行，咱们惟一缺乏的就是一个任务的队列调度处理模块。咱们介绍一种基于gearman的分布式运算框架。 

Gearman是一个用来把工做委派给其余机器、分布式的调用更适合作某项工做的机器、并发的作某项工做在多个调用间作负载均衡、或用来在调用其它语言的函数的系统。 

一个Gearman请求的处理过程涉及三个角色：Client -> Job -> Worker。 

　　 Client：请求的发起者，能够是 C，PHP，Perl，MySQL UDF 等等。 

　　 Job：请求的调度者，用来负责协调把 Client 发出的请求转发给合适的 Work。 

　　 Worker：请求的处理者，能够是 C，PHP，Perl 等等。 

　　 由于 Client，Worker 并不限制用同样的语言，因此有利于多语言多系统之间的集成。甚至咱们经过增长更多的 Worker，能够很方便的实现应用程序的分布式负载均衡架构。 

另外，咱们的离线运算任务每每会存在着针对一类任务一些并发控制，任务去重，防追赶等等功能要求，咱们就能够利用gearman作任务队列，同时作二次开发，利用其余技术手段，如mysql存储介质下的任务数据存储更新和分析，来实现这些并发控制和去重。能够按照以下给出的一种架构来进行离线任务分布式改造: 

 

其中发送端调用统一的api来发送任务到gearman任务队列，而且记录相关任务信息到任务状态记录模块，由部署在运算机上的worker来消费和执行任务。 

   任务发送端的处理逻辑以下图所示: 

 

按照这个流程，任务发送端能够实现任务的去重功能。 

Worker的任务消费流程以下: 

 

这样的结构不只可以实现任务的分布式化执行，并且能够执行一类任务的并发控制，同时经过任务执行前检查机器资源情况，实现对机器资源的基础保护，防止大量任务在集中个别机器上执行，使该服务器出现负荷太重，任务拥塞的状况。 

至此，咱们解决掉存储的中心化和分布式化，任务的分布式化，新的任务的添加也只要归入该框架下运行便可，随着咱们的站点规模的增大，咱们能够方便的加机器进行扩容，透明的进行存储扩容和运算能力扩容，就不会再面临结构上的不可扩展性。 

下面以一个简单的平台应用例子来举例，有一个平台，其存在大量后台cronjob按期任务，也存在各类须要对平台的全量数据等进行批处理运算处理的功能，咱们在架构设计的时候，必须考虑到服务的水平可扩展性，也必需要有高可用性，具有强大的热容灾能力，同时，咱们也须要大量面对cronjob任务的防追赶，加锁，批处理任务的并发执行度控制等问题，下面看看如何设计该平台系统后端架构。 

首先，该平台的存储咱们都使用非本地的存储，包括数据库服务器，相关cache存储，还有分布式文件存储系统以及相关网络访问。 

采用上面介绍的方案采用gearman分布式框架进行部署，2台gearman服务器，6台运算服务器，以主备的模式来使用gearman-server,充当执行任务的队列调度器，在6台机器上各自部署消费worker程序，在另一台机器上部署启用linux系统的crontab，向gearman中发送cronjob任务给gearman,而后，针对任务的去重和并发控制，咱们设计以下的任务记录模块，简单用mysql表来存储相关的任务消息，用于实现防追赶去重和并发控制效果，其中一张关键的任务执行记录表的格式以下: 

 

针对不一样类型的执行任务，咱们能够设置不一样类型的参数 

 

将任务发送端程序和消费并发控制逻辑封装到平台公用模块中，透明的进行调用和任务消费执行 

针对cronjob类型的任务,平台crontab主发送机上添加发送端任务 

*/10 * * * * /home/work/php5/bin/php /home/work/ala-service/bin/cronjob/client_cronjob.php -t $type_id &> /dev/null 

($type_Id为在任务注册表中添加的任务的编号id字段) 

那么注册的任务触发后就会随机分配到6台运算机上去执行。 

而针对应用程序主动调用发送的任务执行方式，咱们只须要在发送端内嵌封装好的发送端程序便可实现任务发送，下面图举一个简单的PHP简单封装的发送端程序调用方式   

发送端只要如此调用便可以发送任务去执行，后端运算机获取任务后进行执行。 

    如此，运营前面所述架构思路，作2次扩展开发，就能够方便的实现该后端平台的需求，其能够方便的水平扩展，机高的可用性，调用方便，实现真正的离线任务分布式化。 

将任务发送端程序和消费并发控制逻辑封装到平台公用模块中，透明的进行调用和任务消费执行 

针对cronjob类型的任务,平台crontab主发送机上添加发送端任务 

*/10 * * * * /home/work/php5/bin/php /home/work/ala-service/bin/cronjob/client_cronjob.php -t $type_id &> /dev/null 

($type_Id为在任务注册表中添加的任务的编号id字段) 

  

那么注册的任务触发后就会随机分配到6台运算机上去执行。 

  

而针对应用程序主动调用发送的任务执行方式，咱们只须要在发送端内嵌封装好的发送端程序便可实现任务发送，下面图举一个简单的PHP简单封装的发送端程序调用方式    

 

发送端只要如此调用便可以发送任务去执行，后端运算机获取任务后进行执行。 

    如此，运营前面所述架构思路，作2次扩展开发，就能够方便的实现该后端平台的需求，其能够方便的水平扩展，机高的可用性，调用方便，实现真正的离线任务分布式化。 

by makaiwen