是否有可能通過累積計劃任務來使工人死鎖？

Question

通過代碼：

@celery.task() 
def some_recursive_task(): 
    # Do some stuff and schedule it to run again later 
    # Note that the next run is not scheduled in a fixed basis, like crontabs 
    # but based on history of some object 
    # Actual task is found here: 
    # https://github.com/rafaelsierra/cheddar/blob/master/src/feeds/tasks.py#L39 
    # Then it call himself again 
    countdown = bla.get_countdown() 
    some_recursive_task.apply_async(countdown=countdown) 

此任務將運行withing接下來的10分鐘和12小時，但這個任務還呼籲應立即運行另一個任務，one for downloading的東西和其他to parse it。

問題是主數據庫中的每條記錄都會調用主函數，假設有幾百個任務正在運行，但考慮到這些任務平均每隔幾個小時運行一次，任務數量並不是什麼大問題。

當我嘗試用單個工作人員運行這個問題時，當我啓動工作人員時，我將其放入運行所有隊列並設置8個併發工作人員，然後開始確認任務，但似乎出現問題即不管將來有多少工作要做，工人都會得到它並等待其計劃運行，這意味着此工人在此之前一直處於鎖定狀態。

我知道我可以將其他兩個函數分成不同的隊列，我已經這樣做了，但是我擔心工人會承認任務要提前12小時運行，並且不會在30分鐘內運行。

工作人員不應該忽視計劃的任務，直到它的時間，並運行那些只是延遲沒有時間？

我不認爲，或者不知道如何，periodic tasks是一個解決方案。

Answer 1

查看積分5 。請記住，countdown與eta這個任務的說法沒有什麼不同。

總之你是對的。單個工人（或任何數量的工人）不應在預定的（eta或countdown）任務上阻塞。

你怎麼知道工人被鎖定？ 計劃的任務從隊列中預取，但在執行之前不會確認。

此外，請記住所有計劃的任務保存在RAM中，直到它們被執行。你希望他們儘可能輕。從我所瞭解的排定的任務不傳遞大塊數據，可能只有一些URI，所以這應該不成問題。

您粘貼的鏈接返回404.您確定cheddar不是私人存儲庫嗎？