gearman杂谈
时间：2010-04-02 来源：CUDev
从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 logger1、logger2、logger3等。 gearman -h host -f logger1 -f logger2 -f logger3 KEYWORD 这就可以可以在所有的机器上grep KEYWORD了。
这种方法不是很灵活，每台机器设置一个func，对上层不透明。
总体来看，gearman适合于那种task数量远远大于worker数量的应用。理论上来看，将计算开销转移到Worker上，从而实现任务的并发执行，表现为client计算负载减轻，用户的等待时间减少。 对Client而言是task，对于Worker而言是job。
后记： gearman的源码还是值得阅读的，对于设计高并发网络程序有些帮助，其中的架构跟我现在项目中用的差不多，但是有一点感觉不错，只有一个维护对应表的逻辑线程，并且尽量减少系统调用。
参考： http://hqlong.com/2010/01/1222.html#more-1222 http://timyang.net/linux/gearman-monitor/ http://blog.s135.com/dips/ http://oddments.org/notes/GearmanOSCONTutorial2009.pdf
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 logger1、logger2、logger3等。 gearman -h host -f logger1 -f logger2 -f logger3 KEYWORD 这就可以可以在所有的机器上grep KEYWORD了。
这种方法不是很灵活，每台机器设置一个func，对上层不透明。
总体来看，gearman适合于那种task数量远远大于worker数量的应用。理论上来看，将计算开销转移到Worker上，从而实现任务的并发执行，表现为client计算负载减轻，用户的等待时间减少。 对Client而言是task，对于Worker而言是job。
后记： gearman的源码还是值得阅读的，对于设计高并发网络程序有些帮助，其中的架构跟我现在项目中用的差不多，但是有一点感觉不错，只有一个维护对应表的逻辑线程，并且尽量减少系统调用。
参考： http://hqlong.com/2010/01/1222.html#more-1222 http://timyang.net/linux/gearman-monitor/ http://blog.s135.com/dips/ http://oddments.org/notes/GearmanOSCONTutorial2009.pdf
相关阅读 更多 +
