前段時間在Django Web平臺開發中，碰到一些請求執行的任務時間較長（幾分鐘），為了加快用戶的響應時間，因此決定采用異步任務的方式在后臺執行這些任務。在同事的指引下接觸了Celery這個異步任務隊列框架，鑒于網上關于Celery和Django結合的文檔較少，大部分也只是粗粗介紹了大概的流程，在實踐過程中還是遇到了不少坑，希望記錄下來幫助有需要的朋友。

一、Django中的異步請求

Django Web中從一個http請求發起，到獲得響應返回html頁面的流程大致如下：http請求發起 -- http handling（request解析） -- url mapping（url正則匹配找到對應的View） -- 在View中進行邏輯的處理、數據計算（包括調用Model類進行數據庫的增刪改查）--將數據推送到template，返回對應的template/response。

圖1. Django架構總覽

同步請求：所有邏輯處理、數據計算任務在View中處理完畢后返回response。在View處理任務時用戶處于等待狀態，直到頁面返回結果。

異步請求：View中先返回response，再在后臺處理任務。用戶無需等待，可以繼續瀏覽網站。當任務處理完成時，我們可以再告知用戶。

二、關于Celery

Celery是基于Python開發的一個分布式任務隊列框架，支持使用任務隊列的方式在分布的機器/進程/線程上執行任務調度。

圖2. Celery架構

圖2展示的是Celery的架構，它采用典型的生產生-消費者模式，主要由三部分組成：broker（消息隊列）、workers（消費者：處理任務）、backend（存儲結果）。實際應用中，用戶從Web前端發起一個請求，我們只需要將請求所要處理的任務丟入任務隊列broker中，由空閑的worker去處理任務即可，處理的結果會暫存在后臺數據庫backend中。我們可以在一臺機器或多臺機器上同時起多個worker進程來實現分布式地并行處理任務。

三、Django中Celery的實現

在實際使用過程中，發現在Celery在Django里的實現與其在一般.py文件中的實現還是有很大差別，Django有其特定的使用Celery的方式。這里著重介紹Celery在Django中的實現方法，簡單介紹與其在一般.py文件中實現方式的差別。

1. 建立消息隊列

首先，我們必須擁有一個broker消息隊列用于發送和接收消息。Celery官網給出了多個broker的備選方案：RabbitMQ、Redis、Database（不推薦）以及其他的消息中間件。在官網的強力推薦下，我們就使用RabbitMQ作為我們的消息中間人。在Linux上安裝的方式如下：

sudo apt-get install rabbitmq-server