beanstalk和rabbitmq區別?

01-24

1. 優勢和劣勢
2. 應用場景

之前做過這方面的隊列服務，也做過這兩者甚至很多隊列的對比測試，先介紹下beanstalkd吧，

首先他們都是一種消息隊列，都能完成一些處理或者請求時間較長的任務，

beantalkd 特有的生產者模型和消費者模型，更再單個隊列任務（job）上有以下特點：

任務優先順序 (priority):

任務 (job) 可以有 0~2^32 個優先順序, 0 代表最高優先順序。 beanstalkd 採用最大最小堆 (Min-max heap) 處理任務優先順序排序, 任何時刻調用 reserve 命令的消費者總是能拿到當前優先順序最高的任務, 時間複雜度為 O(logn)。

延時任務 (delay):

有兩種方式可以延時執行任務 (job): 生產者發布任務時指定延時；或者當任務處理完畢後, 消費者再次將任務放入隊列延時執行 (RELEASE with )。這種機制可以實現分散式的 java.util.Timer，這種分散式定時任務的優勢是：如果某個消費者節點故障，任務超時重發 (time-to-run) 能夠保證任務轉移到另外的節點執行。

任務超時重發 (time-to-run):

Beanstalkd 把任務返回給消費者以後：消費者必須在預設的 TTR (time-to-run) 時間內發送 delete / release/ bury 改變任務狀態；否則 Beanstalkd 會認為消息處理失敗，然後把任務交給另外的消費者節點執行。如果消費者預計在 TTR (time-to-run) 時間內無法完成任務, 也可以發送 touch 命令, 它的作用是讓 Beanstalkd 從系統時間重新計算 TTR (time-to-run)。

任務預留 (buried):

如果任務因為某些原因無法執行, 消費者可以把任務置為 buried 狀態讓 Beanstalkd 保留這些任務。管理員可以通過 peek buried 命令查詢被保留的任務，並且進行人工干預。簡單的, kick 能夠一次性把 n 條被保留的任務踢回隊列。

從下面幾個方面吧。

速度優勢

參考數據：

為什麼可以有這樣的速度？

beanstalkd協議基於ASCII編碼運行在tcp上。客戶端連接伺服器並發送指令和數據，然後等待響應並關閉連接。對於每個連接，伺服器按照接收命令的序列依次處理並響應。所有整型值都非負的十進位數，除非有特別聲明。

場景優勢

就像我在分享時提到的，beanstalkd可以做

延時系統，比如延遲20分鐘發送簡訊，******，在投放的時候就設定一定的延遲時間值，讓任務在延遲時間到了之後進入ready隊列，等待worker預訂處理。

輪詢系統，如下圖，一個被投放的任務，在延遲時間過後需要再檢查一遍狀態，如果不符合，繼續釋放（release with delay）為延遲投放狀態（DELAYED），直到時間過期之後，再次進入ready隊列，被worker預訂，進行一些邏輯判斷，比如微信銀行卡退款是否成功，如果成功，刪除該任務，如果沒成功，繼續釋放（release with delay）為延遲投放狀態。

而這些，都基本上是RabbitMQ做不到的。

分享一個我之前團隊的slide:Beanstalkd-share-slides.pdf_免費高速下載

個人理解，rabbitmq是消息隊列(message queue)，著重點在於保證消息的分發傳遞。

beantalk是任務隊列(task queue)或是說作業隊列(job queue)，著重點在保證任務執行。

從本質上來說他倆是不同的中間件。

beanstalkd 沒有 scale 或者 ha 方案。