1、Beanstalkd是什麼？php
Beanstalkd是一個高性能，輕量級的分佈式內存隊列html
2、Beanstalkd特性python
一、支持優先級(支持任務插隊)
二、延遲(實現定時任務)
三、持久化(定時把內存中的數據刷到binlog日誌)
四、預留(把任務設置成預留，消費者沒法取出任務，等某個合適時機再拿出來處理)
五、任務超時重發(消費者必須在指定時間內處理任務，若是沒有則認爲任務失敗，從新進入隊列)git
3、Beanstalkd核心元素github
生產者 -> 管道(tube) -> 任務(job) -> 消費者安全
Beanstalkd能夠建立多個管道，管道里面存了不少任務，消費者從管道中取出任務進行處理。composer
4、任務job狀態curl
delayed 延遲狀態
ready 準備好狀態
reserved 消費者把任務讀出來，處理時
buried 預留狀態異步
5、安裝Beanstalkd分佈式
http://kr.github.io/beanstalkd/download.html
下載beanstalkd-1.10.tar.gz
> tar -xf beanstalkd-1.10.tar.gz > cd beanstalkd-1.10
> make
查看beanstalkd參數信息
> ./beanstalkd -h
啓動beanstalkd
> ./beanstalkd -l 127.0.0.1 -p 11300 -b /data/beanstalkd/binlog &
-b表示開啓binlog，斷電後重啓自動恢復任務
6、下載Pheanstalk類
首先安裝composer
> curl -sS https://getcomposer.org/installer | php > mv composer.phar /usr/local/bin/composer > composer require pda/pheanstalk
編寫一個簡單腳本查看信息
<?php require './vendor/autoload.php'; use Pheanstalk\Pheanstalk; $p = new Pheanstalk('127.0.0.1', 11300); //查看beanstalkd當前的狀態信息 var_dump($p->stats());
7、Pheanstalk使用方法
維護方法
stats() 查看狀態方法 listTubes() 目前存在的管道 listTubesWatched() 目前監聽的管道 statsTube() 管道的狀態 useTube() 指定使用的管道 statsJob() 查看任務的詳細信息 peek() 經過任務ID獲取任務
生產者方法
putInTube() 往管道中寫入數據 put() 配合useTube()使用
消費者方法
watch() 監聽管道，能夠同時監聽多個管道 ignore() 不監聽管道 reserve() 以阻塞方式監聽管道，獲取任務 reserveFromTube() release() 把任務從新放回管道 bury() 把任務預留 peekBuried() 把預留任務讀取出來 kickJob() 把buried狀態的任務設置成ready kick() 批量把buried狀態的任務設置成ready peekReady() 把準備好的任務讀取出來 peekDelayed() 把延遲的任務讀取出來 pauseTube() 給管道設置延遲 resumeTube() 取消管道延遲 touch() 讓任務從新計算ttr時間，給任務續命
8、使用消息隊列的10個理由：
1. 解耦在項目啓動之初來預測未來項目會碰到什麼需求，是極其困難的。消息隊列在處理過程當中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口。這容許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵照一樣的接口約束。2. 冗餘有時在處理數據的時候處理過程會失敗。除非數據被持久化，不然將永遠丟失。消息隊列把數據進行持久化直到它們已經被徹底處理，經過這一方式規避了數據丟失風險。在被許多消息隊列所採用的"插入-獲取-刪除"範式中，在把一個消息從隊列中刪除以前，須要你的處理過程明確的指出該消息已經被處理完畢，確保你的數據被安全的保存直到你使用完畢。3. 擴展性由於消息隊列解耦了你的處理過程，因此增大消息入隊和處理的頻率是很容易的；只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。4. 靈活性 & 峯值處理能力當你的應用上了Hacker News的首頁，你將發現訪問流量攀升到一個不一樣尋常的水平。在訪問量劇增的狀況下，你的應用仍然須要繼續發揮做用，可是這樣的突發流量並不常見；若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住增加的訪問壓力，而不是由於超出負荷的請求而徹底崩潰。請查看咱們關於峯值處理能力的博客文章瞭解更多此方面的信息。5. 可恢復性當體系的一部分組件失效，不會影響到整個系統。消息隊列下降了進程間的耦合度，因此即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。而這種容許重試或者延後處理請求的能力一般是造就一個略感不便的用戶和一個沮喪透頂的用戶之間的區別。6. 送達保證消息隊列提供的冗餘機制保證了消息能被實際的處理，只要一個進程讀取了該隊列便可。在此基礎上，IronMQ提供了一個"只送達一次"保證。不管有多少進程在從隊列中領取數據，每個消息只能被處理一次。這之因此成爲可能，是由於獲取一個消息只是"預約"了這個消息，暫時把它移出了隊列。除非客戶端明確的表示已經處理完了這個消息，不然這個消息會被放回隊列中去，在一段可配置的時間以後可再次被處理。7.排序保證在許多狀況下，數據處理的順序都很重要。消息隊列原本就是排序的，而且能保證數據會按照特定的順序來處理。IronMO保證消息漿糊經過FIFO（先進先出）的順序來處理，所以消息在隊列中的位置就是從隊列中檢索他們的位置。8.緩衝在任何重要的系統中，都會有須要不一樣的處理時間的元素。例如,加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行--寫入隊列的處理會盡量的快速，而不受從隊列讀的預備處理的約束。該緩衝有助於控制和優化數據流通過系統的速度。9. 理解數據流在一個分佈式系統裏，要獲得一個關於用戶操做會用多長時間及其緣由的整體印象，是個巨大的挑戰。消息系列經過消息被處理的頻率，來方便的輔助肯定那些表現不佳的處理過程或領域，這些地方的數據流都不夠優化。10. 異步通訊不少時候，你不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許你把一個消息放入隊列，但並不當即處理它。你想向隊列中放入多少消息就放多少，而後在你樂意的時候再去處理它們。補充一個： 多語言通訊，好比用php生產一個job，用python或者其餘語言做爲消費者來處理