Gearman是一个用来把工作委派给其他机器、分布式的调用更适合做某项工作的机器、并发的做某项工作在多个调用间做负载均衡、或用来在调用其它语言的函数的系统。Gearman是一个分发任务的程序框架，可以用在各种场合，开源、多语言支持、灵活、快速、可嵌入、可扩展、无消息大小限制、可容错，与Hadoop相比，Gearman更偏向于任务分发功能。它的任务分布非常简单，简单得可以只需要用脚本即可完成。Gearman最初用于LiveJournal的图片resize功能，由于图片resize需要消耗大量计算资 源，因此需要调度到后端多台服务器执行，完成任务之后返回前端再呈现到界面。

gearman的任务传递模式是一对一的，不能实现一对多，一个client通过job server最后只能够到达一个worker上。如果需要一对多，需要定义多个worker的function，依次向这些worker进行发送，非常的不方便。这一点就不如ZeroMQ，ZeroMQ支持的模式很多，能够满足各种消息队列需求。他们用在不同的场合，Gearman是分布式任务系统，而ZeroMQ是分布式消息系统，任务只需要做一次就行。

1. Server

1.1 Gearman工作原理

Gearman 服务有很多要素使得它不仅仅是一种提交和共享工作的方式，但是主要的系统只由三个组件组成： gearmand 守护进程（server），用于向 Gearman 服务提交请求的 client ，执行实际工作的 worker。其关系如下图所示：

Gearmand server执行一个简单的功能，即从client收集job请求并充当一个注册器，而worker可以在此提交关于它们支持的job和操作类型的信息，这样server实际上就充当了Client和Worker的中间角色。Client将job直接丢给server，而server根据worker提交的信息，将这些job分发给worker来做，worker完成后也可返回结果，server将结果传回client。举个例子，在一个公司里面，有老板1、老板2、老板3（client），他们的任务就是出去喝酒唱歌拉项目（job），将拉来的项目直接交给公司的主管（server），而主管并不亲自来做这些项目，他将这些项目分给收手下的员工（worker）来做，员工做完工作后，将结果交给主管，主管将结果报告给老板们即可。

要使用gearman，首先得安装server，下载地址：https://launchpad.net/gearmand。当下载安装完成后，可以启动gearmand，启动有很多参数选项，可以man gearmand来查看，主要的 选项有：

 

• -b, --backlog=BACKLOG       Number of backlog connections for listen. 
• -d, --daemon                Daemon, detach and run in the background. 
• -f, --file-descriptors=FDS  Number of file descriptors to allow for the process                             
• (total connections will be slightly less). Default     is max allowed for user. 
• -h, --help                  Print this help menu. 
• -j, --job-retries=RETRIES   Number of attempts to run the job before the job  server removes it. Thisis helpful to ensure a bad  job does not crash all available workers. Default  is no limit. 
• -l, --log-file=FILE         Log file to write errors and information to. Turning this option on also forces the first  verbose level to be enabled. 
• -L, --listen=ADDRESS        Address the server should listen on. Default is  INADDR_ANY. 
• -p, --port=PORT             Port the server should listen on. 
• -P, --pid-file=FILE         File to write process ID out to. 
• -r, --protocol=PROTOCOL     Load protocol module. 
• -R, --round-robin           Assign work in round-robin order per  workerconnection. The default is to assign work in  the order of functions added by the worker. 
• -q, --queue-type=QUEUE      Persistent queue type to use. 
• -t, --threads=THREADS       Number of I/O threads to use. Default=0. 
• -u, --user=USER             Switch to given user after startup. 
• -v, --verbose               Increase verbosity level by one. 
• -V, --version               Display the version of gearmand and exit. 
• -w, --worker-wakeup=WORKERS Number of workers to wakeup for each job received.   The default is to wakeup all available workers.

 

启动gearmand:

 

若提示没有/var/log/gearman.log这个文件的话，自己新建一个就可以了。

 

1.2 实例化queue与容错

Gearman默认是将queue保存在内存中的，这样能够保障速速，但是遇到宕机或者server出现故障时，在内存中缓存在queue中的任务将会丢失。Gearman提供了了queue实例化的选项，能够将queue保存在数据库中，比如：SQLite3、Drizzle、MySQL、PostgresSQL、Redis(in dev)、MongoDB(in dev).在执行任务前，先将任务存入持久化队列中，当执行完成后再将该任务从持久化队列中删除。要使用db来实例化queue，除了在启动时加入-q参数和对应的数据库之外，还需要根据具体的数据库使用相应的选项，例如使用sqlit3来实例化queue，并指明使用用来存储queue的文件：

 

 

再如使用mysql来实例化queue，选项为：

 

还要创建相应的数据库和表，并创建gearman用户，分配相应的权限：

 

 

可以在gearman的配置文件中加入相关配置，以免每次启动都需要写一堆东西：

 

 

这其实并不是一个很好的方案，因为当使用数据库来实例化queue时，会增加两个步骤：Client和worker必须连接到server上去读写job，并且数据库在处理的速度上也会大大降低。在大并发任务量的情况下，性能会受到直接影响，你会发现SQLite或者mysql并不能满足处理大量BLOB的性能要求，job会不断地积攒而得不到处理，给一个任务犹如石牛如一样海毫无反应。归根结底，需要根据自己的应用场景，合理设计一些测试用例和自动化脚本，通过实际的运行状态进行参数的调整。

job分布式系统一个基本的特点就是要有单点容错能力（no  single point failure），还不能有单点性能瓶颈(no single point of bottleneck)。即：一个节点坏了不影响整个系统的业务，一个节点的性能不能决定整个系统的性能。那如果server挂了该怎么办？解决方法是使用多个server：

 

 

每个client连接多个server，并使用负载最低的那个server，当该server挂掉之后，gearman会自动切换到另一个server上，如下图所示：

 

 

1.3 轮询调度

当job不断地增加时，我们可能需要增加worker服务器来增加处理能力，但你可能会发现任务并不是均匀地分布在各个worker服务器上，因为server分配任务给worker的方式默认按照循序分配的，比如你现有worker-A，在server上注册了5个worker进程，随着任务的增加，又加了一台worker-B，并向同一个server注册了5个worker进程。默认情况下，server会按照worker注册的先后顺序进行调度，即：只有给worker-A分配满任务后才会给worker-B分配任务，即分配方式是w^A, w^A,w^A, w^A,w^A,w^B, w^B,w^B, w^B, w^B。为了能够给worker-A和worker-B均匀地分配任务，server可以采用轮询的方式给worker服务器分配任务，即分配方式为： w^A, w^B, w^A, w^B ...，那么在启动server时加上选项：-R或者--round-robin

 

1.4 受限唤醒

 

根据gearman协议的设计，Worker 如果发现队列中没有任务需要处理，是可以通过发送 PRE_SLEEP 命令给服务器，告知说自己将进入睡眠状态。在这个状态下，Worker 不会再去主动抓取任务，只有服务器发送 NOOP 命令唤醒后，才会恢复正常的任务抓取和处理流程。因此 Gearmand 在收到任务时，会去尝试唤醒足够的 Worker 来抓取任务；此时如果 Worker 的总数超过可能的任务数，则有可能产生惊群效应。而通过 –worker-wakeup 参数，则可以指定收到任务时，需要唤醒多少个 Worker 进行处理，避免在 Worker 数量非常大时，发送大量不必要的 NOOP 报文，试图唤醒所有的 Worker。

 

1.6 线程模型

2. Client

2.1  task与job

2.2 job优先级（priority）

2.3 同步与异步（background）

2.4 阻塞与非阻塞（wait_until_complete）

2.5 送多个job

 

• GearmanClient.submit_multiple_jobs(jobs_to_submit, background=False, wait_until_complete=True, max_retries=0, poll_timeout=None)

Takes a list of jobs_to_submit with dicts of{‘task’: task, ‘data’: data, ‘unique’: unique, ‘priority’: priority}
这里jobs_to_submit是一组job，每个job是上述格式的字典，这里解释一下unique，unique是设置task的unique key，即在小结2.1中的job_request.job.unique的值，如果不设置的话，会自动分配。

• GearmanClient.wait_until_jobs_accepted(job_requests, poll_timeout=None)

Go into a select loop until all our jobs have moved to STATE_PENDING

• GearmanClient.wait_until_jobs_completed(job_requests, poll_timeout=None)

Go into a select loop until all our jobs have completed or failed

• GearmanClient.submit_multiple_requests(job_requests, wait_until_complete=True, poll_timeout=None)

Take Gearman JobRequests, assign them connections, and request that they be done.

• GearmanClient.wait_until_jobs_accepted(job_requests, poll_timeout=None)

Go into a select loop until all our jobs have moved to STATE_PENDING

• GearmanClient.wait_until_jobs_completed(job_requests, poll_timeout=None)

Go into a select loop until all our jobs have completed or failed

 

3 worker

3.1 主要API

3.2 简单示例

3.2 返回结果

 server信息

5.2  GearmanJobRequest

跟踪运行中的job状态