[[335445]]

本文轉(zhuǎn)載自微信公眾號「新鈦云服」，作者黃平安 。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。

做項(xiàng)目時，其中用了Celery這種工具。前段時間，遇到過一些問題，解決后沒有進(jìn)行總結(jié)，今天就抽個空把它記錄下來。

用過Celery的程序員，都知道它是一種異步執(zhí)行程序的工具。里面有Worker、Task等概念，這里我就不贅述了。

1、功能需求

在使用Celery的過程中，我需要知道Task的狀態(tài)。Task就是異步任務(wù)，用戶沒執(zhí)行一次異步任務(wù)，就會新創(chuàng)建一個Task，代表此異步任務(wù)。

該Task對象中，包含著許多信息，其中也包括狀態(tài)。我的項(xiàng)目中，需要根據(jù)Task的狀態(tài)來判斷，這次異步任務(wù)是否還在執(zhí)行中。

2、 出現(xiàn)問題

既然，我需要Task的狀態(tài)，那我就需要查看Task的狀態(tài)怎么獲取啊!我查看了一下Celery的源碼!發(fā)現(xiàn)在Celery的AsyncResult對象中，有個state字段。如下圖所示：

根據(jù)，該源碼中的注釋說明，該字段有好幾個值。分別是：PENDING、STARTED、RETRY、FAILURE、SUCCESS。

然后，我就趕緊寫個demo驗(yàn)證一下，看看這個state字段是不是我想要的。demo如下：

我執(zhí)行項(xiàng)目中的Celery異步任務(wù)，根據(jù)我之前查出來的task id。執(zhí)行demo查詢該Task的狀態(tài)。

這時候，問題就出來了，根據(jù)demo返回的Task狀態(tài)為PENDING。表示Task還在等待中，尚未執(zhí)行。

這就不對了，此時的狀態(tài)應(yīng)該是STARTED，因?yàn)槲业腡ask已經(jīng)執(zhí)行好一段時間了，它返回的結(jié)果不準(zhǔn)確。

3、 解決問題

難道我用的字段不正確，然后我就谷歌搜索。發(fā)現(xiàn)Celery官網(wǎng)和網(wǎng)上的大多數(shù)反饋也是表示Task的狀態(tài)字段就是state。

那我為什么測出的結(jié)果和理論的不同呢?然后，我詳細(xì)查看Celery的配置，發(fā)現(xiàn)了一個參數(shù)：CELERY_TRACK_STARTED。

該參數(shù)默認(rèn)是關(guān)閉的，表示只要Celery開始執(zhí)行Task就會追蹤該Task。所以，開啟該參數(shù)后，Task的狀態(tài)是時刻記在BACKEND中的。

好，我在Celery的配置文件處，加了該參數(shù)。

然后再執(zhí)行Celery的異步任務(wù)，得到的結(jié)果是我想要的。

4、 引申思考以及問題

我的問題是解決了，但是這引起了我對Celery的一些興趣。

當(dāng)時，我就考慮到，如果我把正在運(yùn)行中的Task任務(wù)，直接kill掉。那么此時我再去看Task的狀態(tài)，它會是啥呢?

STARTED，正在執(zhí)行中的狀態(tài)。

而此時，Task已經(jīng)關(guān)掉，它不應(yīng)該是這種狀態(tài)。為此，我猜測這應(yīng)該是，Task意外結(jié)束，沒有改變Task的狀態(tài)導(dǎo)致的。

但是這樣就不太好了，因?yàn)橹灰浅绦颍撬鸵欢ㄓ幸馔馔顺龅目赡堋＜僭O(shè)，我的項(xiàng)目需要查看Task的狀態(tài)，當(dāng)Task被意外kill掉時，項(xiàng)目中查看Task的狀態(tài)就不準(zhǔn)確了。

5、 引申問題解決思路一

當(dāng)時我想：既然Task被kill掉之后，還能顯示運(yùn)行中，說明此Task的狀態(tài)一定是保存在某個地方，我把該Task的數(shù)據(jù)清空了不就完了。

而Celery的數(shù)據(jù)存儲，只有可能存在三個地方：使用RabbitMQ的消息代理(BROKER)，使用Redis的任務(wù)結(jié)果保存處(BACKEND)，以及文件保存(當(dāng)然這點(diǎn)基本上沒可能，Celery沒這樣用過，我主要是死馬當(dāng)活馬醫(yī))。

這三個地方，其實(shí)只有Redis可能存放Task的狀態(tài)，按照Celery的機(jī)制，也只有它最有可能存放。

但是呢?為了弄清Celery的存儲機(jī)制，我想試試Celery會把數(shù)據(jù)存到RabbitMQ中嗎?然后，我執(zhí)行了，以下命令，清空RabbitMQ隊列。

此時，RabbitMQ隊列的數(shù)據(jù)已經(jīng)為空。然后我查看Task的狀態(tài)，依然還為STARTED。說明不是它存儲Task的狀態(tài)。

然后，我進(jìn)入redis中。使用keys *命令，發(fā)現(xiàn)許多帶有celery-task-meta前綴的記錄。

后經(jīng)查明，這些記錄的后綴就是Celery中Task的id。

我根據(jù)我的Task的id，查出如下內(nèi)容：

我們能清晰的看出，內(nèi)容中Task的狀態(tài)為STARTED。這說明的確是存放在Redis中的。然后，我把這條記錄刪除，再執(zhí)行demo，Task的狀態(tài)不再是STARTED，項(xiàng)目中顯示的狀態(tài)就正確了。

但是，這又引出了一個問題，怎么刪除這條記錄，或者什么時候刪除這條記錄。當(dāng)然，我們刪除很容易，編程語言的redis模塊或者Celery自己提供的代碼都能刪除。Celery中根據(jù)task id刪除backend中的數(shù)據(jù)。

那么，什么時候刪除這條記錄呢?Celery默認(rèn)的是保留此數(shù)據(jù)24小時。我左思右想，還是不刪這條記錄了。換種思路解決這個問題吧!

6、 引申問題解決思路二

要知道，Celery的Task是運(yùn)行在Worker上的。只要判斷此時的Worker程序是否還正常運(yùn)行，不就可以判斷Task的狀態(tài)是否還在運(yùn)行中了嗎?

說干就干，我們通過ps命令，可以查看Celery運(yùn)行的程序。

然后，我們執(zhí)行task時，把它本身運(yùn)行的程序進(jìn)程pid記錄下來，發(fā)現(xiàn)正好就是Worker的進(jìn)程pid。

這樣就簡單了，我們只需要結(jié)合Celery提供查看Task狀態(tài)的接口，以及Python提供的Psutil查看進(jìn)程的模塊。就能最終判斷Task是不是真在運(yùn)行中。只有Task的狀態(tài)為STARTED，并且Task所在的Worker進(jìn)程在運(yùn)行中，Task才是真正在運(yùn)行狀態(tài)。

Psutil查看進(jìn)程是否運(yùn)行代碼如下：

7、 總結(jié)

今天只是把我前段時間遇到的問題以及解決思路記錄下來，也沒寫Celery的內(nèi)部機(jī)制等等，這些東西網(wǎng)上一大把，我也不是很有寫它們的必要。

做過幾年的程序員，感觸最多的就是解決問題的思路。一旦遇到某個問題了，一種思路解決不了，可以換種思路解決，另一種思路可能也不一定能完美解決，但可以加深對問題的理解。而怎么想到另一種思路，就需要平時的多積累和提高自己的認(rèn)知范圍了，這還是比較難的。