任务分发，请使用gearman

1. 一般，多语言多系统之间的集成是个大问题，通常来讲，人们多半会采用WebService的方式来处理此类集成问题，但无论采用何种风格的 WebService，如RPC风格，或者REST风格，其自己都有必定的复杂性。相比之下，Gearman也能实现相似的做用，并且更简单易用。  
2. 一个Gearman请求的处理过程涉及三个角色：Client -> Job -> Worker。  
3. Client：请求的发起者，能够是C，PHP，Perl，MySQL UDF等等。  
4. Job：请求的调度者，用来负责协调把Client发出的请求转发给合适的Work。  
5. Worker：请求的处理者，能够是C，PHP，Perl等等。  
6. 由于Client，Worker并不限制用同样的语言，因此有利于多语言多系统之间的集成  
7.   
8.   
9. gearman另外一个应用方面是负载分担，你能够将worker放在不一样的服务器（或者一些列服务器）上，好比你的php程序须要图片转换，可是不但愿本 地服务器有太多的这样图片转换的进程，那么你能够创建一系列服务器，在上面加载worker处理图片转换。这样你的web服务器将不受图片转换的影响，同 时你获得了负载均衡的功能，由于jobserver会在请求到来的时候，将这个请求发给空闲的worker.一样对于多核的服务器，你能够在同一机器上创 建一样数目的worker.你可能担忧，jobserver处于一个中心，那么这会是一个单点的瓶颈，若是死了，会怎么样？对于这样的状况，你能够运行多 个jobserver。这样若是一个jobserver down了，client和worker会自动迁移到另外一台jobserver上。 

从08年开始，所谓的云计算开始流行起来，什么分布式计算模型、分布式消息队列、分布式存储系统各类新鲜事物。

gearman，从名字上看叫作“齿轮工”，就是经过齿轮把不一样的组件组合在一块儿。一般，多语言多系统之间的集成是项目开发中一个比较头疼的问题。通常会采用RPC风格或者是REST风格的WebService。可是总感受比较麻烦。gearman就应运而生了，做为一个任务分发架构，它可以轻松的将前端的任务经过Job Server分发给后端的Worker处理。Gearman请求的处理过程涉及三个角色：Client -> Job Server -> Worker。

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

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

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

工做原理图：

工做流：

由于Client，Worker并不限制用同样的语言，因此有利于多语言多系统之间的集成。

甚至咱们经过增长更多的Worker，能够很方便的实现应用程序的分布式负载均衡架构。

集群架构：

关于gearman的分布式任务处理：

1. 其实每个任务处理的时间并无下降，相反会稍稍有所增长，主要是数据在网络上传输的一些时间。

2. 前端Client（一般是web服务器）的负载下降了，可是转移到了后端Worker上。

计算不可能凭空消失，只不过从一台机器转移到了另一台机器。

3. 同步方式的话，前端Client（一般是Web服务器）等待的时间与后端Worker的数量与当前任务数有关。若是任务数量<=Worker数量，前端Client等待的时间约等于一个任务处理的时间。

可是当任务数>=Worker数量时，就会出现某些Client等待的状况，某个Client只有等到一个空闲的Worker，才会将任务交给它进行处理。

设想一下，在任务数<=Worker数量的时候，使用gearman是能够提升响应时间的。若是采用单机话，N个任务仍是在一台机器上运行，每一个任务须要

如今有N个任务(Client)，M个Worker，每一个任务执行时间为t。若是不是用gearman的话，须要的时间为N*t，平均等待时间为N*t/2。

若是使用了gearman的话，而且N<=M，须要的时间为t，平均等待时间为t；若是N>M的话，须要的时间为(N/M)*t or (N/M+1)*t。

test.sh

#!/bin/sh

sleep 10

echo "TEST"

开启2个Worker

./gearman -w -f test /home/wangyao/test.sh

开启3个Client：

date;./gearman -f test;date

三个结果分别为：

--------------------------------------------

Wed Mar 17 14:41:31 CST 2010

TEST 

Wed Mar 17 14:41:41 CST 2010

--------------------------------------------

Wed Mar 17 14:41:32 CST 2010

TEST 

Wed Mar 17 14:41:42 CST 2010

--------------------------------------------

Wed Mar 17 14:41:34 CST 2010

TEST 

Wed Mar 17 14:41:51 CST 2010

--------------------------------------------

能够看出前两个Client的任务都用了10s，可是第3个任务却花了17s。主要在于当第3个任务执行的时候，没有空闲的Worker执行任务，必须等到一个Worker空闲下来，最早空闲的Worker要在14:41:41，在这个时刻执行第3个任务，如今已通过去了7s，再须要10s完成任务，所以第3个任务最终用了17s。

4. 异步方式的话，任务交给后端Worker后，前端Client就返回了，这样用户体验比较好。可是，存在任务执行失败或者是任务结果反馈的问题。

通常采用数据库做为存储，将任务执行的状态信息、结果等存入数据库；前端Client按期检查数据库中的结果，再进一步进行操做，是向用户呈现结果仍是从新执行任务。

一个应用实例：

Client将log发送到专门的log服务器:

tail -f access_log | gearman -h host -f logger

可能会有多个log服务器，log服务器将接受到的log信息写入到一个文件中：

gearman -w -h host -f logger > log_file

进行分布式grep，须要在每台log服务器设置一个function：

gearman -w host -f logger1 ./dgrep.sh

#!/bin/sh

read pattern

grep $pattern log_file

相应的在其余log服务器上建立logger2，logger3等。

如今，日志已经在日志服务器上了。咱们在其余机器上，想对日志进行分布式的grep。只须要做为一个client，调用worker logger一、logger二、logger3等。

gearman -h host -f logger1 -f logger2 -f logger3 KEYWORD 

这就能够能够在全部的机器上grep KEYWORD了。

这种方法不是很灵活，每台机器设置一个func，对上层不透明。

整体来看，gearman适合于那种task数量远远大于worker数量的应用。理论上来看，将计算开销转移到Worker上，从而实现任务的并发执行，表现为client计算负载减轻，用户的等待时间减小。

对Client而言是task，对于Worker而言是job。

后记：管理工具

Gearman-Monitor

GearmanManager