Gearman简介

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 Client：它提供Gearman Client API给咱们的应用程序调用，API能够使用是 C，PHP，Perl，MySQL UDF 等等语言，它是请求的发起者。   Gearman Job Server：将客户端的请求分发到各个Gearman Worker的调度者，至关于中央控制器，它不负责处理具体业务逻辑。
Gearman Worker：它提供Gearman Worker API给应用程序调用，具体负责客户端的请求，并将处理结果返回给客户端。

集群架构：

       

Job Server 能够开启多个实例，这样在其中一个发生故障的时候，能够 Failover 到其余的机器上。同时 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。