Celery中文翻译-Application
Celery在使用前必須實例化,稱為application或app。app是線程安全的,具有不同配置、組件、task的多個Celery應用可以在同一個進程空間共存。
# 創建Celery應用 >>> from celery import Celery >>> app = Celery() >>> app <Celery __main__:0x100469fd0>最后一行文本化顯示了Celery應用:包含應用所屬類的名稱,當前主模塊名,以及內存地址。唯一重要的信息是模塊名稱。
Main Name
在Celery中發送task消息時,該消息僅包含要執行的task的名稱。每一個worker維護一個task名稱和對應函數的映射,這稱為task registry。
當定義一個task時,該task將注冊到本地:
>>> @app.task ... def add(x, y): ... return x + y>>> add <@task: __main__.add>>>> add.name __main__.add>>> app.tasks['__main__.add'] <@task: __main__.add>當Celery無法檢測task函數屬于哪個模塊時,使用main模塊名生成初始task名稱。
這種方式僅適用于以下兩種場景:
如果直接運行tasks.py,task名將以__main__為前綴,但如果tasks.py被其他程序導入,task名將以tasks為前綴。如下:
>>> from tasks import add >>> add.name tasks.add也可以直接指定主模塊名:
>>> app = Celery('tasks') >>> app.main 'tasks'>>> @app.task ... def add(x, y): ... return x + y>>> add.name tasks.addConfiguration
可以通過直接設置,或使用專用配置模塊對Celery進行配置。
通過app.conf屬性查看或直接設置配置:
>>> app.conf.timezone 'Europe/London'>>> app.conf.enable_utc = True或用app.conf.update方法一次更新多個配置:
>>> app.conf.update( ... enable_utc=True, ... timezone='Europe/London', ...)config_from_object
app.config_from_object()方法從配置模塊或對象中導入配置。需要注意的是:調用config_from_object()方法將重置在這之前配置的任何設置。
使用模塊名
app.config_from_object()方法接收python模塊的完全限定名(fully qualified name)或具體到其中的某個屬性名,例如"celeryconfig", "myproj.config.celery", 或"myproj.config:CeleryConfig":
只要能夠正常執行import celeryconfig,app就能正常配置。
使用模塊對象
也可以傳入一個已導入的模塊對象,但不建議這樣做。
更推薦使用模塊名的方式,因為這樣在使用prefork pool時不需要序列化該模塊。如果在實際應用中出現配置問題或序列化錯誤,請嘗試使用模塊名的方式。
使用配置類或對象
from celery import Celeryapp = Celery()class Config:enable_utc = Truetimezone = 'Europe/London'app.config_from_object(Config)config_from_envvar
app.config_from_envvar()方法從環境變量中接收配置模塊名。
import os from celery import Celery#: Set default configuration module name os.environ.setdefault('CELERY_CONFIG_MODULE', 'celeryconfig')app = Celery() app.config_from_envvar('CELERY_CONFIG_MODULE')通過環境變量指定配置模塊:
$ CELERY_CONFIG_MODULE="celeryconfig.prod" celery worker -l infoCensored configuration
如果要顯示Celery配置,可能需要過濾某些敏感信息如密碼、密鑰等。Celery提供了幾種用于幫助顯示配置的實用方法。
humanize()
該方法返回列表字符串形式的配置,默認只包含改動過的配置,如果要顯示內置的默認配置,設置with_defaults參數為True:
table()
該方法返回字典形式的配置:
Celery可能不會移除所有的敏感信息,因為它使用正則表達式匹配鍵并判斷是否移除。如果用戶添加了包含敏感信息的自定義配置,可以使用Celery可能標記為敏感配置的名稱來命名(API, TOKEN, KEY, SECRET, PASS, SIGNATURE, DATABASE)。
Laziness
應用實例是惰性的。
創建Celery實例只會執行以下操作:
app.task()裝飾器不會在task定義時立即創建task,而是在task使用時或finalized應用后創建。
下例說明了在使用task或訪問其屬性前,都不會創建task:
>>> @app.task >>> def add(x, y): ... return x + y>>> type(add) <class 'celery.local.PromiseProxy'>>>> add.__evaluated__() False>>> add # <-- causes repr(add) to happen <@task: __main__.add>>>> add.__evaluated__() True應用的Finalization指顯式地調用app.finalize()方法或隱式地訪問app.tasks屬性。
finalized應用將會:
Breaking the chain
雖然可以依賴于當前應用,但最佳實踐是將應用實例傳遞給任何需要它的對象,這個行為可以稱為app chain。
# 依賴于當前應用(bad)from celery import current_appclass Scheduler(object):def run(self):app = current_app # 傳遞應用實例(good)class Scheduler(object):def __init__(self, app):self.app = app在開發模式設置CELERY_TRACE_APP環境變量,可以在應用鏈斷開時拋出異常:
$ CELERY_TRACE_APP=1 celery worker -l infoAbstract Tasks
使用task()裝飾器創建的task都繼承自celery.app.task模塊的Task基類。繼承該類可以自定義task類:
from celery import Task # 或者 from celery.app.task import Taskclass DebugTask(Task):def __call__(self, *args, **kwargs):print('TASK STARTING: {0.name}[{0.request.id}]'.format(self))return super(DebugTask, self).__call__(*args, **kwargs)如果要重寫__call__()方法,記得調用super。這樣在task直接調用時會執行基類的默認事件。
Task基類是特殊的,因為它并未綁定到任何特定的應用。一旦task綁定到應用,它將讀取配置以設置默認值等。
通過base參數指定基類
@app.task(base=DebugTask) def add(x, y):return x + y通過app.Task屬性指定基類
>>> from celery import Celery, Task>>> app = Celery()>>> class MyBaseTask(Task): ... queue = 'hipri'>>> app.Task = MyBaseTask >>> app.Task <unbound MyBaseTask>>>> @app.task ... def add(x, y): ... return x + y>>> add <@task: __main__.add>>>> add.__class__.mro() [<class add of <Celery __main__:0x1012b4410>>,<unbound MyBaseTask>,<unbound Task>,<type 'object'>]總結
以上是生活随笔為你收集整理的Celery中文翻译-Application的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: DOM的那些事
- 下一篇: Grails通过sessionId获取s