Celery用戶指引–Workers啓動、重啓
1.啓動worker
通過下面的命令在前臺啓動worker
$ celery -A proj worker -l info- 1
通過下面的命令查看worker命令的所有相關選項
$ celery worker --help- 1
你也可以在同一臺機器上啓動多個worker。
如果這樣做你需要用包含hostname參數的節點名來使每個worke有r唯一的名字。
$ celery -A proj worker --loglevel=INFO --concurrency=10 -n worker1.%h
$ celery -A proj worker --loglevel=INFO --concurrency=10 -n worker2.%h
$ celery -A proj worker --loglevel=INFO --concurrency=10 -n worker3.%h- 1
- 2
- 3
hostname參數可以擴展成以下變量:
%h:包括域名的主機名
%n:只包含主機名
%d:只包含域名
舉例，如果當前的主機名是george.example.com,則分別可以擴展成以下幾種形式:
worker1.%h -> worker1.george.example.com
worker1.%n -> worker1.george
worker1.%d -> worker1.example.com- 1
- 2
- 3
注意：
要使用%需要使用2個%,比如%%h.
2.停止worker
終止worker是通過TERM信號實現的。
向worker發送了shutdown命令後，worker在實際終止前會執行完當前所有正在執行的任務。所以如果這些任務很重要，你需要等待worker結束而不要採取其它極端手段（如發送KILL信號）。
如果worker在一段時間後仍然沒有停止，比如因爲task中有死循環，你可以使用KILL信號強制終止worker.但是注意當前正在執行的任務將會丟失（除非task設置了acks_late選項）。
因爲KILL信號不能捕獲，所以worker不能捕捉子進程的狀態，你需要手工確認。下面是常用的技巧:
$ ps auxww | grep 'celery worker' | awk '{print $2}' | xargs kill -9- 1
3.重啓worker
重啓一個worker，你需要發送TERM信號然後啓動一個新實例。在開發過程中最簡單的管理workers的方法是使用”celery multi”:
$ celery multi start 1 -A proj -l info -c4 --pidfile=/var/run/celery/%n.pid
$ celery multi restart 1 --pidfile=/var/run/celery/%n.pid- 1
- 2
在生產環境中，你需要使用初始化腳本或者其它進程管理系統( Running the worker as a daemon)。
除了停止worker再啓動它，你還可以使用HUP信號來重啓worker。但是注意worker會負責重啓自己，所以使用HUP可能會引起問題，不建議在生產環境中使用。
$ kill -HUP $pid- 1
注意:
通過HUP重啓worker僅適用於在後臺運行的worker,因爲它沒有控制終端。
HUP在macOS上是禁用的，因爲平臺的限制。
4.進程信號
worker主進程會處理以下信號:
TERM 熱重啓，等待任務運行結束.
QUIT 冷重啓,儘快終止進程
USR1 dump所有活動線程的堆棧.
USR2 遠程調試, 查看 celery.contrib.rdb.
文件路徑中可以使用的變量
–logfile,–pidfile,–statedb中的文件路徑參數可以包含一些被worker擴展的變量：
節點名替換:
%p: 節點全名.
%h: 包含域名的主機名.
%n: 只有主機名.
%d: 只有域名.
%i: Prefork 進程池中的進程索引，如果是主進程則爲0.
%I: Prefork 進程池中的進程索引，包含分隔符 .
比如當前的主機名是 [email protected] 下面的變量將會被擴展爲:
–logfile-%p.log -> [email protected]
–logfile=%h.log -> foo.example.com.log
–logfile=%n.log -> george.log
–logfile=%d -> example.com.log
Prefork進程池索引
prefork進程池索引將會根據進程實需要打開的文件擴展成不同的文件名。
這可以用來爲每個子進程指定唯一的日誌文件。
注意，進程池索引的數字與進程上限有關，不管進程是否退出還是設置了時間段內的每個子進程的最大任務數。所以，這個數字是進程索引而不是進程的數量或者pid。
%i - 進程池索引，主進程是 0 .
Where -n [email protected] -c2 -f %n-%i.log將會產生以下3個日誌文件:
worker1-0.log (主進程)
worker1-1.log (進程1)
worker1-2.log (進程2)
%I - 包含分隔符的進程索引.
Where -n [email protected] -c2 -f %n%I.log 將會產生以下3個日誌文件:
worker1.log (主進程)
worker1-1.log (進程1)
worker1-2.log (進程2)
5.併發
默認情況下，使用multiprocessing實現任務的併發執行，但是你也可以使用Eventlet.worker的進程和線程數量可以通過concurrency參數來改變。默認情況下，這個數量和可用的CPU個數相同。
進程的數量 (multiprocessing/prefork pool)
通常情況下進程越多越好, 但是會有一個臨界點增加更多的進程會導致相反的效果。有跡象表明運行多個worker實例會比運行單個worker有更好的效果。比如3個worker,每個worker有10個進程. 你需要經驗來找到最適合你的worker數量, 這通常與你的應用，任務負載和任務運行時間和其它因素有關。
6.遠程控制
2.0中的新特性
通過一個高優先級的廣播消息隊列，worker可以被遠程控制。遠程控制命令可以直接作用在所有的worker上或者指定workers列表。
命令也可以有應答，客戶端可以等待應答。由於沒有一箇中心控制的worker,所以沒有辦法知道集羣中有多少個workers，也沒有辦法估計有多少workers會返回一個應答，所以客戶端有一個超時的配置－－－等待應答的截止期限—這個期限以秒爲單位，默認爲1秒。如果worker在截止期限內沒有收到應答，也不一定說明worker不會應答，更壞的情況是worker掛掉了，但是也有可能僅僅是因爲網絡延遲或者是worker在很慢的處理命令，所以可以適當的調整這個超時時間。
除了超時時間，客戶端還可以指定等待的最大應答個數。如果指定了目標，這個限制會被設置爲目的主機的個數。
注意
單一進程也支持控制命令, 但是所有的任務將會阻塞等待控制命令的執行，所以在worker忙碌時需要限制此命令的使用。在這種情況下，你必須增加客戶端等待應答的超時時間.
轉自：http://blog.csdn.net/happyanger6/article/details/51793490