待解決的問題
最近在做一個服務器集群管理的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 系統的線程數是有限制的，但這要耗時任務多了，如果然服務器去等，不管啥策略都很可能吧服務器整垮。