Beanstalkd 的理解
Beanstalkd 是一個輕量級的內存型隊列，利用了和Memcache 類似的協議。其官網beanstakkd官網 下方的感謝語說：
Many thanks to memcached for providing inspiration for simple protocol design and for the structure of the documentation. Not to mention a fantastic piece of software!
對於其底層協議感興趣的可以去github上看，介紹的很清楚。本文只對beanstalkd 的應用提供思路上的闡釋，不列舉具體的代碼。直到beanstalkd 能夠干什么，才能夠再實踐中去應用。但是怎么用beanstalkd 干活解決問題，則要去網上看beanstalkd 的API,每種語言的都有，可以各取所需。
Beanstalkd 的意思是魔豆，他的隊列管理器叫做tube。一般的隊列都是先進先出，適合N:M 的生產者消費者處理模型。想象一下如下的模型：我們的業務中經常需要適應高並發的場景，當1萬個用戶同時訪問某個接口時，為了響應服務，我們需要盡可能的加速接口的響應效率。有時候我們只負責提交任務，而不關注任務是否處理成功或者失敗。這時候使用過程化的思路解決問題，就會受到牽制。假若盲目的增加機器，壓榨mysql的性能，還是不能阻擋十萬、百萬並發。這時候可以考慮使用異步去處理，接口收到請求之后，立刻將任務放進隊列里，新啟一台腳本機，起若干進程來消費任務。
為什么要使用Beanstalkd
實際業務中，有時候會出現隊列與隊列之間相互依賴的情況。比如A,B兩個隊列。A負責往數據庫中insert數據，而B隊列負責update數據。只有插入數據庫后，我們才能進行update。但是如果同時開兩個隊列。因為隊列執行的先后是不可控的，這就造成了B update的時候，不知道A是否已經insert。另外比如Reids的隊列機制，一但消費者從隊列中取出了一個job。但是由於神奇的原因，失敗掉了，怎么辦？任務就這樣丟失了，這個任務再也處理不掉了。
帶着這些問題，我們交給BeansTalkd來解決。
理解Beanstalkd的隊列機制
Beanstalkd 是CS結構，有Server端和Client段之分。Server端都是一樣的，負責存儲和消費隊列任務。但是Client端由於各種語言各種框架，就各部相同。
任務在隊里之中被稱作Job. 一個Job 再Beanstalkd中有以下的生命周期：
- put:將一個任務放置進tube中
- deayed: 這個任務現在再等待中，需要若干秒才能准備完畢【延遲隊列】
- ready: 這個任務已經准備好了，可以消費了。所有的消費都是要從取ready狀態的job
- reserved: 這個任務已經被消費者消費。
- release: 這個job執行失敗了，把它放進ready狀態隊列中。讓其他隊列執行。
- bury:這個job執行失敗了，但不希望其他隊列執行，先把它埋起來。
這是一個job生命周期的主要狀態，如果有講的不全的，可以去翻看API.
各種語言的演示代碼都大同小異，這里就不浪費紙張了。