在這些場景下，任務佇列是有效的解決方案。
在乙個任務佇列系統中，「將新鮮事推送至使用者a的所有好友」或者「查詢當前最熱門的十大文獻」這種查詢或者計算工作可以被當成乙個「任務」。
在任務佇列系統中，一般有任務生產者、任務處理中間方以及任務處理者三方。
在生產方、消費者和任務處理中間方之間一般使用訊息傳遞的方式來進行通訊。
在任務佇列系統框架中，任務處理者可以跨越不同的服務節點，可以動態地增加節點來增加系統的任務處理能力，非常適合高併發、需要橫向擴充套件的 web 服務後台。
celery是基於python語言的開源分布式任務排程模組。
它有著簡明的 api，並且有豐富的擴充套件性，適合用於構建分布式的web服務。
celery的結構圖如下：
在上圖中，一共可以分為五個部分：
celery beat（定時任務處觸發）
broker（任務佇列）
workers（任務處理者）
result store（執行結果儲存）
下面，我們依次來了解這五個部分的作用:
任務生產者 (task producer)
任務生產者 (task producer) 負責產生計算任務，交給任務佇列去處理。
在 celery 裡，一段獨立的 python **、一段嵌入在 django web 服務裡的一段請求處理邏輯，只要是呼叫了 celery 提供的 api，產生任務並交給任務佇列處理的，我們都可以稱之為任務生產者。
任務排程器 (celery beat)
celery beat 是乙個任務排程器，它以獨立程序的形式存在。
celery beat 程序會讀取配置檔案的內容，周期性地將執行任務的請求傳送給任務佇列。
celery beat 是 celery系統自帶的任務生產者。
系統管理員可以選擇關閉或者開啟 celery beat。
同時在乙個 celery 系統中，只能存在乙個celery beat排程器。
任務** (broker)
任務**方負責接受任務生產者傳送過來的任務處理訊息，存進佇列之後再進行排程，分發給任務消費方 (celery worker)。
因為任務處理是基於 message(訊息) 的，所以我們一般選擇 rabbitmq、redis 等訊息佇列或者資料庫作為 celery 的 message broker。
任務消費方 (celery worker)
celery worker 就是執行任務的一方，它負責接收任務處理中間方發來的任務處理請求，完成這些任務，並且返回任務處理的結果。
celery worker 對應的就是作業系統中的乙個程序。
celery 支援分布式部署和橫向擴充套件，我們可以在多個節點增加 celery worker 的數量來增加系統的高可用性。
在分布式系統中，我們也可以在不同節點上分配執行不同任務的 celery worker 來達到模組化的目的。
結果儲存
celery 支援任務處理完後將狀態資訊和結果的儲存，以供查詢。
celery 內建支援 rpc, django orm，redis，rabbitmq 等方式來儲存任務處理後的狀態資訊。
使用Celery實現定時任務功能
python實現定時任務的方式有很多，如使用celery schedule模組 threading模組中的timer sched模組 定時框架apscheduler，都各有特色。在多次對比之後，我決定使用celery，下面我們介紹一下如何使用celery。首先安裝celery pip install...
celery配置與基本使用
定義celery例項,需要的引數,1,例項名,2,任務發布位置,3,結果儲存位置 mycelery broker redis 任務存放的地方 backend redis 結果存放的地方 defadd x,y return x y 1.啟動celery 1.1 單程序啟動celery celery a...
celery配置與基本使用
定義celery例項,需要的引數,1,例項名,2,任務發布位置,3,結果儲存位置 mycelery broker redis 任務存放的地方 backend redis 結果存放的地方 defadd x,y return x y 測試時一般使用併發數高的 1.啟動celery 1.1 單程序啟動ce...