有那个网站可以做报名链接的,个人网站主机选择,软件开发和软件研发,建设网站用户名是什么意思待解决的问题最近在做一个服务器集群管理的web项目#xff0c;需要处理一些极其耗时的操作#xff0c;比如磁盘格式化分区。对于这个需求#xff0c;最开始的想法是#xff0c;为了让节点上的rpc(远程过程调用) service端尽可能简单(简单到只需要popen执行一条指令即可需要处理一些极其耗时的操作比如磁盘格式化分区。对于这个需求最开始的想法是为了让节点上的rpc(远程过程调用) service端尽可能简单(简单到只需要popen执行一条指令即可有时间我再专门写一篇博客讲讲这个项目的rpc是如何实现的)我们选择了让web端直接等待处理结果那么问题来了如何保证用户不必等待又能保证任务准确的执行呢简单的rpc结构如下图以往在处理一些稍微耗时的操作可以通过优化代码结构优化数据库操作次数起一些线程来处理一些简单的比如发邮件生成大的压缩文件提取视频缩量图服务器间互访等等操作来避免用户在web页面的等待。但现在这个操作显然不能用之前的这些方法做因为现在的操作哪怕只执行一次都是非常耗时的更何况可能需要处理的可能是上百上千台服务器。这是在线程层面很难做要知道在响应请求的web进程中起一个线程来做的话在响应完断开tcp连接之后这个进程很可能被kill掉像Apache就是这样当然可以通过配置改变apache的行为但显然不太靠谱。更好的做法是在web服务器上起一个守护进程去做这个事情那么问题就在于如何创建守护进程了好在laravel帮我们考虑了这个事情。Laravel的队列laravel的队列默认是以sync(同步)的方式来处理多个任务这显然不是我们想要的。鉴于这个项目使用的是laravel4.1版本我选择了beanstalkd来实现异步处理多个任务。其中beanstalkd是一种比较专业的队列服务驱动器是一个常驻后台服务我们可以通过它提供的接口来把任务提交给它由它创建的守护进程来执行队列。配置队列执行环境1.安装beanstalkd服务我开发的电脑为CentOS5.4版本比较低所以装的过程中还是遇到些麻烦首先执行下面的指令1 wget ftp://fr2.rpmfind.net/linux/epel/5/ppc/epel-release-5-4.noarch.rpm2 rpm -ivh epel-release-5-4.noarch.rpm3 yummakecache4 yum search beanstalkd但最后发现找不到这个软件于是将yum的源换成了163的1 cd /etc/yum.repos.d2 wget http://mirrors.163.com/.help/CentOS5-Base-163.repo3 mv CentOS-Base.repo CentOS-Base.repo.bak再次makecache install 就OK了安装完后启动beanstalkd服务1 service beanstalkd start另外可以搜索到beanstalkd的配置文件放在了sysconfig下为laravel添加beanstalkd的驱动beanstalkd的php驱动包为pda/pheanstalk进入laravel的protected目录composer.json在这个目录下执行1 composer require pda/pheanstalk 2.*出现如下的错误可以看出镜像地址响应 502所以需要给composer找一个可用的镜像 http://www.phpcomposer.com/修改~/.composer/config.json如下然后回到protected目录再执行前面安装驱动的命令安装这回出现了不一样的错误上面的php包中第一个是为了phpstorm的对laravel更好的支持后面一个symfony/yaml已经安装并不需要升级所以修改composer.json直接将这两个项目删除掉就行了删除完之后再次执行安装命令安装可以看到终于成功了可以通过 composer show -i 查看安装了哪些包测试在TestController中添加一个action1 class TestController extendsBaseController2 {34 public functiongetQueue(){5 //6 Log::info(添加一个对列任务);7 Queue::push(SendEmail,array(message哈哈));8 Log::info(任务添加完毕);9 exit;10 }1112 }在app目录下新建tasks目录并修改protected/composer.json和app/global.php将这个目录加到类加载路径中修改global.php1 ClassLoader::addDirectories(array(23 app_path()./commands,4 app_path()./controllers,5 app_path()./models,6 app_path()./database/seeds,7 app_path()./library,8 app_path()./tasks,9 ));修改composer.json1 classmap: [2 app/commands,3 app/controllers,4 app/models,5 app/database/migrations,6 app/database/seeds,7 app/tasks,8 app/tests/TestCase.php9 ]以后的耗时调度任务的代码就放在这个目录下面了首先新建一个BaseTask.php1 /**2 * Created by PhpStorm.3 * User: Administrator4 * Date: 2015/8/19 00195 * Time: 11:556 */7 abstract classBaseTask8 {9 public abstract function fire($job,$data);10 }然后新建一个SendMail.php1 /**2 * Created by PhpStorm.3 * User: Administrator4 * Date: 2015/8/19 00195 * Time: 11:506 */7 class SendEmail extendsBaseTask8 {910 public function fire($job, $data)11 {12 //TODO: Implement fire() method.13 Log::info(对列任务执行.json_encode($data).Time : .time());14 sleep(30);15 Log::info(对列任务执行完毕.time());16 //将任务从队列冲删除17 $job-delete();18 //将任务返回到队列1920 // $job-release();2122 }23 }最后就是去修改config目录下的配置文件queue.php文件了修改为1 default beanstalkd,1 beanstalkd array(2 driver beanstalkd,3 host localhost,4 queue default,5 ttr 60,6 ),关于ttr的解释这里有一个表示time to run 这个参数可以覆盖默认参数让Beanstalkd 检测是否在这个时间内完成至此配置和写代码完成在shell中执行要在protected目录下artisan文件在这个目录下1 php artisan queue:work2 php artisan queue:listen查看protected/app/storage/logs/laravel.log 可以看到下面的内容508-478 刚好30秒下面测试一个实际的问题印象中apache服务器与客户端在请求完成断开连接后会kill掉负责处理的httpd进程只有配置了keep-alive参数在会将进程保留到apache进程池中所以但用户请求一个耗时操作之后关闭了浏览器这个处理耗时任务的守护进程会不会也被kill掉呢当然其实有点多虑了当响应完成之后tcp链接已经被断开掉了如果进程会被kill掉那么早就kill掉了跟你浏览器关没关应该没多大关系还是试试吧实践才是硬道理这里将SendMial中的sleep时间改长一点改为 600秒最后发现没有执行完可以看到listen报出异常很显然执行超时看来是前面设置的ttr的问题将ttr注释掉或者修改掉更高的值发现还是不行最后在仔细看看报错信息发现所以改变命令的执行方式1 php artisan queue:listen --timeout800最后命令任务成功执行完毕可以看到 1353-753 600 刚刚好另外看样子 这个任务对列应该是被保存起来了当我没有启动 listen时任务怎么都不会处理但我一但启动listen前面添加的任务就会立马执行但最后还是有个问题这个是对列形式进行处理要启动下一个对列任务必须等上一个对列任务执行完毕不过之前曾看到过一个work对应一个任务队列那么我完全可以起多个任务队列有点多核CPU的调度哦。更好的办法最后再跟一位大神讨论了一下探讨出了另外一个更加优秀的办法虽然会加重节点上rpc service代码的复杂度不过也不是很麻烦。这种方式就是回调管理集群的web服务器可以不用等待只需如下步骤通过web服务器上的rpc client向要执行耗时操作的节点上的rpc service发送一条指令节点上的rpc service收到指令后不先执行指令而是马上向web服务器也就是rpc client返回一个任务ID。web服务器将这个id作为一条任务记录保存到数据库。节点上的rpc service处理指令至于处理指令也是在节点上在单独起一个进程 P 来处理因为rpc service也不能让rpc client傻等着处理进程 P 处理完了之后将执行结果和任务ID作为参数回调web服务器的一个web接口web服务器接到rpc service的回调之后通过ID查找到任务更新任务的执行状态更新数据很显然这种方式更加可靠也大大减轻了web 服务器的负担要知道Linux 系统的线程数是有限制的但这要耗时任务多了如果然服务器去等不管啥策略都很可能吧服务器整垮。