laravel隊列-讓守護進程處理耗時任務


待解決的問題

最近在做一個服務器集群管理的web項目,需要處理一些極其耗時的操作,比如磁盤格式化分區。對於這個需求,最開始的想法是,為了讓節點上的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.rpm
2 rpm -ivh epel-release-5-4.noarch.rpm
3 yum makecache
4 yum search beanstalkd

但最后發現找不到這個軟件,於是將yum的源換成了163的

1 cd /etc/yum.repos.d
2 wget http://mirrors.163.com/.help/CentOS5-Base-163.repo
3 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中添加一個action

 1 class TestController extends BaseController
 2 {
 3   
 4     public function getQueue(){
 5         //
 6         Log::info("添加一個對列任務");
 7         Queue::push('SendEmail',array('message'=>'哈哈'));
 8         Log::info('任務添加完畢');
 9         exit;
10     }
11 
12 }

在app目錄下新建tasks目錄,並修改protected/composer.json和app/global.php,將這個目錄加到類加載路徑中

修改global.php

1 ClassLoader::addDirectories(array(
2 
3    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.json

1 "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.php"
9 ]

以后的耗時調度任務的代碼就放在這個目錄下面了

首先新建一個BaseTask.php

 1 /**
 2  * Created by PhpStorm.
 3  * User: Administrator
 4  * Date: 2015/8/19 0019
 5  * Time: 11:55
 6  */
 7 abstract class BaseTask
 8 {
 9     public abstract  function fire($job,$data);
10 }

然后新建一個SendMail.php

 1 /**
 2  * Created by PhpStorm.
 3  * User: Administrator
 4  * Date: 2015/8/19 0019
 5  * Time: 11:50
 6  */
 7 class SendEmail extends BaseTask
 8 {
 9 
10     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         //  將任務返回到隊列
19 
20 //        $job->release();
21 
22     }
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:work
2 php artisan queue:listen

然后訪問url,http://192.168.1.10/ssanlv/test/queue,可以發現請求馬上就完成了,頁面並沒有等待

查看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 --timeout=800

最后命令任務成功執行完畢

可以看到 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 系統的線程數是有限制的,但這要耗時任務多了,如果然服務器去等,不管啥策略都很可能吧服務器整垮。

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM