最近的專案要使用非同步的任務佇列，初步選用了Celery，比較輕量級，但是對Task，Broker，Worker等概念有些理解的不透徹，找到以下文章，甚是透徹。 
當我們需要處理一些比較耗時的任務時，我們就需要考慮啟用“非同步”這個概念。 
比如以下兩種情況：

一，頻繁讀寫 
比如說，現在你一條“微博”，如果是使用 push 的機制，那則需要將這條“微博”告知所有關注你的人。 
（這裡是假設。實際的微博是使用推拉結合的方式） 
關注你的人是100，則 insert 100次。 
假如你是個大V，關注你的人有100000人,則需要 insert 100000次。 
如果使用同步的方式，那恭喜你，你發完一條微博，這個時間夠你喝杯咖啡了。

二，使用“不可靠”的服務 
這裡的不可靠，指的並不是它不能使用，而是指它不穩定。 
當你呼叫第三方的簡訊介面，app push介面，無法預計呼叫介面的時間，這次呼叫，可能使用0.01s，但下次則變成3s。 
這在生產環境是完全可能發生的。高併發，網路異常都可能造成這種情況。

如果這個任務不需要及時返回結果，那我們就可以將這些任務丟給後臺去處理，某些實時性要求比較高的任務，還是隻能同步進行。 
常規的使用場景：簡訊服務、圖片處理服務、群發email、第三方介面呼叫。 
mx

在這裡我推薦 celery 。Celery 是一個非同步任務佇列/基於分散式訊息傳遞的作業佇列。 
celery_128

這裡有幾個概念，task、worker、broker。 
顧名思義，task 就是老闆交給你的各種任務，worker 就是你手下幹活的人員。

那什麼是 Broker 呢？

老闆給你下發任務時，你需要 把它記下來， 這個它 可以是你隨身攜帶的本子，也可以是 電腦裡地記事本或者excel，或者是你的 任何時間管理工具。

Broker 則是 Celery 記錄task的地方。 
作為一個任務管理者的你，將老闆（前端程式）發給你的 安排的工作（Task） 記錄到你的本子（Broker）裡。接下來，你就安排你手下的IT程式猿們（Worker），都到你的本子(Broker)裡來取走工作（Task）

tasks

Celery本身不儲存“資料”，需要配合各種後端訊息佇列一起工作。 
官方推薦的是 rabbitmq。 
rabbitmq有些臃腫（需要安裝erlang）,但效能比較穩健。在大資料高併發的情況下，出隊與入隊的速度基本持平。 
redis， 作為一個支援list的key-value資料庫，也可以當成小型的佇列服務來使用。