待解決的問題
最近在做一個服務器集群管理的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 }
1 'default' => 'beanstalkd',
1 'beanstalkd' => array( 2 'driver' => 'beanstalkd', 3 'host' => 'localhost', 4 'queue' => 'default', 5 'ttr' => 60, 6 ),
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 系統的線程數是有限制的,但這要耗時任務多了,如果然服務器去等,不管啥策略都很可能吧服務器整垮。