Background Worker: Beanstalkd, Amazon SQS, Resque

今天準備要把手上的東西從Amazon SQS完全的換到Resque了

最早的時候,這東西的queue是用beanstalkd做的(我還寫了篇Beanstalkd的介紹。)剛開始一切都很順利,速度相當快。一直到production負載越來越高,beanstalkd開始不斷的吃光CPU。在始終找不到解決辦法的情況下把整個系統用Amazon SQS重寫

Amazon SQS算是相當的簡單易用,但是提供的功能也相當少,沒有retry,沒有delayed,只有一個很難用的visibility設定。SQS也替我們稱了相當久的時間,不過最後還是因為一些因素讓我開始考慮其他的解決辦法了:

1. 速度不快:將job push進queue的latency就從10ms ~ 500ms不等,在一個只有50ms左右的API request中實在顯得太慢了。而且不只是push進去慢,worker pull job的速度也不高。

2. 費用高:當job的量越來越大的時候,worker數量也越來越多。SQS的worker是採用不停去poll SQS的方式來取得job的。可是SQS每一個request都是要錢的!每次小小的費用累積起來也是相當的可觀

3. 難以管理:在使用的過程中,不管是要監控queue的job count,檢查worker status等等都非常的困難。在實務上常常會產生許多的麻煩。雖然在我寫文章的這時,看到amazon終於提供了基本的管理介面

綜合以上理由,最後我還是決定把整個job queue搬到Resque上。Resque速度非常快,管理介面也相當好用,本身對job queue與worker的操作能力就不錯,加上各式各樣的plugin(目前用了resque-retry, resque-scheduler, resque-status),目前而言還算是相當滿意

廣告

Background Worker: Beanstalkd, Amazon SQS, Resque” 有 3 則迴響

  1. 我倒是從resque跳到beanstalkd,主要是job大多是i/o希望以更輕量快速的node.js解決。但最近發現個嚴重問題,在分配jobs時竟然不是atomic,雖是偶爾發生,但發生就很煩人,請問您有遇過這個問題嗎?謝謝

  2. poga, 我是用fivebeans這個node.js client去操作jobs,一般來說是先connect再use再put或其它動作,原本我是做完所有動作時會在最後end()去結束連線,目前是發現不要做end()就沒這個問題,我再跟作者詢問看看,謝謝。

迴響已被關閉。