分散式佇列神器 Celery

發表於2017-01-12

Celery 是什麼?

Celery 是一個由 Python 編寫的簡單、靈活、可靠的用來處理大量資訊的分散式系統,它同時提供操作和維護分散式系統所需的工具。

Celery 專注於實時任務處理,支援任務排程。

說白了,它是一個分散式佇列的管理工具,我們可以用 Celery 提供的介面快速實現並管理一個分散式的任務佇列。

1.快速入門

(本文以 Celery4.0 為基礎進行書寫)

首先,我們要理解 Celery 本身不是任務佇列,它是管理分散式任務佇列的工具,或者換一種說法,它封裝好了操作常見任務佇列的各種操作,我們用它可以快速進行任務佇列的使用與管理,當然你也可以自己看 rabbitmq 等佇列的文件然後自己實現相關操作都是沒有問題的。

Celery 是語言無關的,雖然它是用 Python 實現的,但他提供了其他常見語言的介面支援。只是如果你恰好使用 Python 進行開發那麼使用 Celery 就自然而然了。

想讓 Celery 執行起來我們要明白幾個概念:

1.1 Brokers

brokers 中文意思為中間人,在這裡就是指任務佇列本身,Celery 扮演生產者和消費者的角色,brokers 就是生產者和消費者存放/拿取產品的地方(佇列)

常見的 brokers 有 rabbitmq、redis、Zookeeper 等

1.2 Result Stores / backend

顧名思義就是結果儲存的地方,佇列中的任務執行完後的結果或者狀態需要被任務傳送者知道,那麼就需要一個地方儲存這些結果,就是 Result Stores 了

常見的 backend 有 redis、Memcached 甚至常用的資料都可以。

1.3 Workers

就是 Celery 中的工作者,類似與生產/消費模型中的消費者,其從佇列中取出任務並執行

1.4 Tasks

就是我們想在佇列中進行的任務咯,一般由使用者、觸發器或其他操作將任務入隊,然後交由 workers 進行處理。

理解以上概念後我們就可以快速實現一個佇列的操作:

這裡我們用 redis 當做 celery 的 broker 和 backend。

(其他 brokers 與 backend 支援看這裡)

安裝 Celery 和 redis 以及 python 的 redis 支援:

這裡需要注意如果你的 celery 是 4.0 及以上版本請確保 python 的 redis 庫版本在 2.10.4 及以上,否則會出現 redis 連線 timeout 的錯誤,具體參考

然後,我們需要寫一個task:

OK,到這裡,broker 我們有了,backend 我們有了,task 我們也有了,現在就該執行 worker 進行工作了,在 tasks.py 所在目錄下執行:

意思就是執行 tasks 這個任務集合的 worker 進行工作(當然此時broker中還沒有任務,worker此時相當於待命狀態)

最後一步,就是觸發任務啦,最簡單方式就是再寫一個指令碼然後呼叫那個被裝飾成 task 的函式:

執行此指令碼

delay 返回的是一個 AsyncResult 物件,裡面存的就是一個非同步的結果,當任務完成時result.ready() 為 true,然後用 result.get() 取結果即可。

到此,一個簡單的 celery 應用就完成啦。

2. 進階用法

經過快速入門的學習後,我們已經能夠使用 Celery 管理普通任務,但對於實際使用場景來說這是遠遠不夠的,所以我們需要更深入的去了解 Celery 更多的使用方式。

首先來看之前的task:

這裡的裝飾器app.task實際上是將一個正常的函式修飾成了一個 celery task 物件,所以這裡我們可以給修飾器加上引數來決定修飾後的 task 物件的一些屬性。

首先,我們可以讓被修飾的函式成為 task 物件的繫結方法,這樣就相當於被修飾的函式 add 成了 task 的例項方法,可以呼叫 self 獲取當前 task 例項的很多狀態及屬性。

其次,我們也可以自己複寫 task 類然後讓這個自定義 task 修飾函式 add ,來做一些自定義操作。

2.1 根據任務狀態執行不同操作

任務執行後,根據任務狀態執行不同操作需要我們複寫 task 的 on_failure、on_success 等方法:

嗯, 然後繼續執行 worker:

執行指令碼,得到:

分散式佇列神器 Celery
再修改下tasks:

重新執行 worker,再執行 trigger.py:

分散式佇列神器 Celery

可以看到,任務執行成功或失敗後分別執行了我們自定義的 on_failure、on_success

2.2 繫結任務為例項方法

然後重新執行:

分散式佇列神器 Celery
執行中的任務獲取到了自己執行任務的各種資訊,可以根據這些資訊做很多其他操作,例如判斷鏈式任務是否到結尾等等。

關於 celery.task.request 物件的詳細資料可以看這裡

2.3 任務狀態回撥

實際場景中得知任務狀態是很常見的需求,對於 Celery 其內建任務狀態有如下幾種:

引數 說明
PENDING 任務等待中
STARTED 任務已開始
SUCCESS 任務執行成功
FAILURE 任務執行失敗
RETRY 任務將被重試
REVOKED 任務取消

當我們有個耗時時間較長的任務進行時一般我們想得知它的實時進度,這裡就需要我們自定義一個任務狀態用來說明進度並手動更新狀態,從而告訴回撥當前任務的進度,具體實現:

然後在 trigger.py 中增加:

然後執行任務:
分散式佇列神器 Celery

2.4 定時/週期任務

Celery 進行週期任務也很簡單,只需要在配置中配置好週期任務,然後在執行一個週期任務觸發器( beat )即可:

新建 Celery 配置檔案 celery_config.py:

配置中 schedule 就是間隔執行的時間,這裡可以用 datetime.timedelta 或者 crontab 甚至太陽系經緯度座標進行間隔時間配置,具體可以參考這裡

如果定時任務涉及到 datetime 需要在配置中加入時區資訊,否則預設是以 utc 為準。例如中國可以加上:

然後在 tasks.py 中增加要被週期執行的任務:

然後重新執行 worker,接著再執行 beat:

分散式佇列神器 Celery

可以看到週期任務執行正常~

2.5 鏈式任務

有些任務可能需由幾個子任務組成,此時呼叫各個子任務的方式就變的很重要,儘量不要以同步阻塞的方式呼叫子任務,而是用非同步回撥的方式進行鏈式任務的呼叫:

錯誤示範

正確示範1

正確示範2

鏈式任務中前一個任務的返回值預設是下一個任務的輸入值之一 ( 不想讓返回值做預設引數可以用 si() 或者 s(immutable=True) 的方式呼叫 )。

這裡的 s() 是方法 celery.signature() 的快捷呼叫方式,signature 具體作用就是生成一個包含呼叫任務及其呼叫引數與其他資訊的物件,個人感覺有點類似偏函式的概念:先不執行任務,而是把任務與任務引數存起來以供其他地方呼叫。

2.6 呼叫任務

前面講了呼叫任務不能直接使用普通的呼叫方式,而是要用類似 add.delay(2, 2) 的方式呼叫,而鏈式任務中又用到了 apply_async 方法進行呼叫,實際上 delay 只是 apply_async 的快捷方式,二者作用相同,只是 apply_async 可以進行更多的任務屬性設定,比如 callbacks/errbacks 正常回撥與錯誤回撥、執行超時、重試、重試時間等等,具體引數可以參考這裡

2.7 關於 AsyncResult

AsyncResult 主要用來儲存任務執行資訊與執行結果,有點類似 tornado 中的 Future 物件,都有儲存非同步結果與任務執行狀態的功能,對於寫 js 的朋友,它有點類似 Promise 物件,當然在 Celery 4.0 中已經支援了 promise 協議,只需要配合 gevent 一起使用就可以像寫 js promise 一樣寫回撥:

要注意的是這種 promise 寫法現在只能用在 backend 是 RPC (amqp) 或 Redis 時。 並且獨立使用時需要引入 gevent 的猴子補丁,可能會影響其他程式碼。 官方文件給的建議是這個特性結合非同步框架使用更合適,例如 tornado、 twisted 等。

delayapply_async 生成的都是 AsyncResult 物件,此外我們還可以根據 task id 直接獲取相關 task 的 AsyncResult: AsyncResult(task_id=xxx)

關於 AsyncResult 更詳細的內容,可以參考這裡

利用 Celery 進行分散式佇列管理、開發將會大幅提升開發效率,關於 Celery 更詳細的使用大家可以去參考詳細的官方文件

相關文章