一、Celery和RabbitMQ簡單介紹
Celery是一個基于Python開發的分布式異步消息隊列，可以輕松實作任務的異步處理。它的基本工作就是管理配置設定任務到不同的伺服器，并且取得結果。至于說伺服器之間是如何進行通信的？這個Celery本身不能解決。
Celery在執行任務時需要一個消息中間件來接收和發送任務消息，以及存儲任務結果，一般使用RabbitMQ 或 Redis，我們這裡隻讨論Celery+RabbitMQ，其他的組合方式讀者可以查閱更多資料。
RabbitMQ是一個由Erlang語言開發的AMQP的開源實作。AMQP即Advanced Message Queue，進階消息隊列協定。它是應用層協定的一個開放标準，為面向消息的中間件設計，基于此協定的用戶端與消息中間件可傳遞消息，并不受産品、開發語言等條件的限制。
在Celery+RabbitMQ組合中，RabbitMQ作為一個消息隊列管理工具被引入到和Celery內建，負責處理伺服器之間的通信任務。
那麼有一個疑問：RabbitMQ作為消息管理系統已經可以實作異步的發送消息，為什麼還要使用Celery?
Celery相當于包裝了一個現成的系統，可以友善的在項目中操作RabbitMQ這個消息隊列媒體，減少在RabbitMQ上編寫腳本的任務。最直接的例子就是在Celery Python裡，隻需要config一下settings，然後就可以用decorator輕松使用消息隊列，而不用在RabbitMQ上編寫複雜的腳本。
當然，Celery也支援和Redis、MongoDB之類的組合，原因是RabbitMQ盡管足夠強大，但對于一些相對簡單的業務環境來說可能太多（複雜）了一些。
二、Celery+RabbitMQ是如何工作的？
關于Celery和RabbitMQ的協作方式，可以通過工作上的一些案例來說明：
假設A公司最近在開下年度工作會議，會議上要确定下一年的工作内容和計劃，參會人員有老闆（下發任務者）、部門主管（Celery配置設定任務者）、部門員工（工作者）、老闆秘書（溝通協調者RabbitMQ）。
那麼這場會議首先需要确定的是下一年的具體工作内容，這裡就稱之為“任務内容”。比如老闆說我們下一年要開發出一款社交類APP産品，部門主管表示贊同，于是便愉快地定下了具體的工作任務（task），當然開發一款社交類APP産品是這個項目的總任務，其中可以細分成很多小的任務，比如業務流程是怎麼樣的？界面怎麼設計等。
在确定了具體工作任務後，老闆便把這個項目交給了部門主管（Celery），部門主管确定部門員工中誰去完成這項任務，于是指定某個人（Worker），也可以多個人。
釋出工作任務的人是老闆（下發任務者），他指定了部門主管（Celery）什麼時候去完成哪些任務，并要求擷取回報資訊。但有一點需要注意，老闆隻管布置任務，不參與具體的任務配置設定，這個任務配置設定的工作是交給部門主管（Celery）去執行。
項目之初，老闆（下發任務者）通過公司會議将任務傳遞給部門主管（Celery），部門主管通過部門會議将任務配置設定給員工（Worker），過段時間再将任務結果回報給老闆。然而随着任務越來越多，部門主管發現任務太多，每個任務都要回報結果，記不住，也容易弄亂，導緻效率下降。
在召開會議商量了一番後，老闆秘書（溝通協調者RabbitMQ）站起來說：“我有個提議，老闆每天将布置的任務寫成一張紙條放到我這，然後部門主管每天早上來取并交給員工，至于紙條上的任務如何配置設定，部門主管決定就行，但是要将結果同樣寫一張紙條回報給我，我再交給老闆。這樣老闆隻負責下發任務，我隻負責保管任務紙條，部門主管隻負責配置設定任務并擷取回報，員工隻負責按任務工作。大家職責都很明确，效率肯定會更高。”至此，老闆與員工的溝通問題也解決了。
任務的處理方式如下圖1-1:
Celery+RabbitMQ是如何工作的
三、後續
下一篇文章我将具體講講它們在代碼上的協助方式。