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给应用程序调用，具体负责客户端的请求，并将处理结果返回给客户端。
集群架构：
关于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。