摘要：結(jié)論執(zhí)行完任務(wù)不釋放內(nèi)存與原一直沒有被銷毀有關(guān)，因此可以適當(dāng)配置小點，而任務(wù)并發(fā)數(shù)與配置項有關(guān)，每增加一個必然增加內(nèi)存消耗，同時也影響到一個何時被銷毀，因為是均勻調(diào)度任務(wù)至每個，因此也不宜配置過大，適當(dāng)配置。

? 監(jiān)控task的執(zhí)行結(jié)果：任務(wù)id，結(jié)果，traceback，children，任務(wù)狀態(tài)

? 配置 backend="redis://127.0.0.1:6379/5"給Celery的app對象，直接在redis中查看

? 還可以

? 健壯celery：celery -A proj worker -l info

?  proj  tree
├── __init__.py 
├── celery.py | app=Clery("proj",include=["proj.tasks"])
                app.config_from_object("proj.config")
                if __name__==__main__： app.start()
├── config.py |  CELERY_RESULT_BACKEND = "redis://127.0.0.1:6379/6"
                BROKER_URL = "redis://127.0.0.1:6379/5"      
└── tasks.py  |  @app.task            # 注意這個文件名必須是tasks.py
                def add(x, y): return x + y             

? tasks可以有多個在celery.py中添加一行代碼加載任務(wù)函數(shù)

? app.autodiscover_tasks(["proj.sms", "proj.email"])

? Scheduler計劃定時任務(wù)：celery -A proj worker -B -l info

#config.py
CELERY_TIMEZONE = "Asia/Shanghai" # 指定時區(qū)
from datetime import timedelta
CELERYBEAT_SCHEDULE = {
    "add-every-30-seconds": {
         "task": "proj.tasks.add", # 指定要執(zhí)行的函數(shù)任務(wù)
         "schedule": timedelta(seconds=30), # 指定計劃時間間隔30s執(zhí)行一次task
         "args": (16, 16)
    },
}

? celery.schedules import crontab定時周期任務(wù)：（比如每周一執(zhí)行一次 ）

? 只需要修改 "schedule": crontab(hour=7, minute=30, day_of_week=1),

? 指定隊列名：

? 啟動加上-Q參數(shù) celery -A proj worker --loglevel=info -Q "testq"

? 跑任務(wù)時 add.delay(3,4,queue="testq")

? 指定開啟的worker進程數(shù)：單個Celery進程每分鐘就可以處理數(shù)百萬個任務(wù)

? 底層是調(diào)用的Python的multiprocessing模塊中的Pool進程池思想來做

? 啟動加上-c參數(shù) celery -A proj worker --loglevel=info -c 2 2個worker進程來同時搶任務(wù)

? 圖像化查看broker里面的數(shù)據(jù)，查看任務(wù)狀態(tài)，以及任務(wù)的詳細信息:flower的webUI

? pip install flower 注意創(chuàng)建celery實例app時指定的broker設(shè)置的redis/5

? 任意目錄執(zhí)行 celery flower --port=5555 --broker=redis://localhost:6379/5

? 應(yīng)用： django調(diào)用celery跑異步任務(wù)，常見場景有注冊成功，發(fā)送郵件可以異步來防止網(wǎng)絡(luò)IO阻塞，以及耗時間的任務(wù)，可以在WEB應(yīng)用中使用這種異步方式

安裝django-celery==3.1.17 與celery==3.1.17對應(yīng)

創(chuàng)建celery必須的數(shù)據(jù)庫表結(jié)構(gòu) python manage.py migrate

django項目的settings.py文件中追加如下內(nèi)容：backend，任務(wù)執(zhí)行結(jié)果超時時間，worker并發(fā)數(shù)也就是 -c 指定的數(shù)據(jù)，指定任務(wù)周期存儲在orm數(shù)據(jù)庫中

在django的app應(yīng)用目錄下創(chuàng)建tasks.py任務(wù)文件@task def add(x,y):

開啟django服務(wù)和celery服務(wù)，雖然耦合了，還要開python manage.py celery worker --loglevel=info

celery內(nèi)存泄露分析

celery配置項如下

CELERYD_CONCURRENCY = 2??????celery worker并發(fā)數(shù)
CELERYD_MAX_TASKS_PER_CHILD = 5???每個worker最大執(zhí)行任務(wù)數(shù)

?
執(zhí)行celery -A ansibleAPI.celery worker啟動celery，通過ps -ef | grep celery可以看到兩個celery worker進程（8226，8228）。

利用celery worker進行某個任務(wù)，當(dāng)worker沒有執(zhí)行到最大任務(wù)時（即銷毀重建），每執(zhí)行一次任務(wù)占用內(nèi)存必然有所增加，任務(wù)數(shù)為9，10時（celery均勻調(diào)度，并發(fā)數(shù)*最大任務(wù)數(shù)），分別有原8228 worker被銷毀，重新創(chuàng)建9386 worker及原8226 worker被銷毀，重新創(chuàng)建9564 worker，此時，運行第9次時，占用總內(nèi)存有所下降，運行第10次時，總內(nèi)存回到初如值，同樣任務(wù)執(zhí)行第19、20次情況類似。

celery并發(fā)計算規(guī)則
celery任務(wù)并發(fā)只與celery配置項CELERYD_CONCURRENCY 有關(guān)，與CELERYD_MAX_TASKS_PER_CHILD沒有關(guān)系，即CELERYD_CONCURRENCY=2，只能并發(fā)2個worker，此時任務(wù)處理較大的文件時，執(zhí)行兩次可以看到兩個task任務(wù)并行執(zhí)行，而執(zhí)行第三個任務(wù)時，開始排隊，直到兩個worker執(zhí)行完畢。

結(jié)論
celery執(zhí)行完任務(wù)不釋放內(nèi)存與原worker一直沒有被銷毀有關(guān)，因此CELERYD_MAX_TASKS_PER_CHILD可以適當(dāng)配置小點，而任務(wù)并發(fā)數(shù)與CELERYD_CONCURRENCY配置項有關(guān)，每增加一個worker必然增加內(nèi)存消耗，同時也影響到一個worker何時被銷毀，因為celery是均勻調(diào)度任務(wù)至每個worker，因此也不宜配置過大，適當(dāng)配置。