最近的項目要使用異步的任務隊列，初步選用了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數據庫，也可以當成小型的隊列服務來使用。