標籤:

Python程序中不同的重啟機制

分析典型案例:

  1. Celery 分散式非同步任務框架
  2. Gunicorn Web容器

之所以挑這兩個,不僅僅是應用廣泛,而且兩個的進程模型比較類似,都是Master、Worker的形式,在熱重啟上思路和做法又基本不同,比較有參考意義

知識點:

  • atexit
  • os.execv

  • 模塊共享變數
  • 信號處理
  • sleep原理:select
  • 文件描述符共享

這幾個知識點不難,區別只在於Celery和Gunicorn的應用方式。如果腦海中有這樣的知識點,這篇文章也就是開闊下視野而已。。。

Celery和Gunicorn都會在接收到HUP信號時,進行熱重啟操作

Celery的重啟:關舊Worker,然後execv重新啟動整個進程

Gunicorn的重啟:建立新Worker,再關舊Worker,Master不動

下面具體的看下它們的操作和核心代碼。

對於Celery:

def _reload_current_worker():n platforms.close_open_fds([n sys.__stdin__, sys.__stdout__, sys.__stderr__,n ])n os.execv(sys.executable, [sys.executable] + sys.argv)n n n ndef install_worker_restart_handler(worker, sig=SIGHUP):n def restart_worker_sig_handler(*args):n """Signal handler restarting the current python program."""n import atexitn atexit.register(_reload_current_worker)n from celery.worker import staten state.should_stop = EX_OKn platforms.signals[sig] = restart_worker_sig_handlern

HUP上掛的restart_worker_sig_handler 就做了兩件事:

  1. 註冊atexit函數
  2. 設置全局變數

考慮到這個執行順序,應該就能明白Celery 是Master和Worker都退出了,嶄新呈現。。

看過APUE的小夥伴,應該比較熟悉 atexit 了,這裡也不多說。os.execv還挺有意思,根據Python文檔,這個函數會執行一個新的函數用於替換掉當前進程,在Unix里,新的進程直接把可執行程序讀進進程,保留同樣的PID。

在Python os標準庫中,這是一整套基本一毛一樣的函數,也許應該叫做函數族了:

  • os.execl(path, arg0, arg1, ...)
  • os.execle(path, arg0, arg1, ..., env)
  • os.execlp(file, arg0, arg1, ...)
  • os.execlpe(file, arg0, arg1, ..., env)
  • os.execv(path, args)
  • os.execve(path, args, env)
  • os.execvp(file, args)
  • os.execvpe(file, args, env)

以exec開頭,後綴中的l和v兩種,代表命令行參數是否是變長的(前者不可變),p代表是否使用PATH定位程序文件,e自然就是在新進程中是否使用ENV環境變數了

然後給worker的state.should_stop變數設置成False。。。 模塊共享變數 這個是Python FAQ里提到的一種方便的跨模塊消息傳遞的方式,運用了Python module的單例。我們都知道Python只有一個線程,所以單例的變數到處共享

而should_stop這個變數也是簡單粗暴,worker在執行任務的循環中判斷這個變數,即執行非同步任務->查看變數->獲得非同步任務->繼續執行 的循環中,如果True就拋出一個【應該關閉】異常,worker由此退出。

這裡面有一個不大不小的坑是:信號的發送對於外部的工具,例如kill,是非阻塞的,所以當HUP信號被發出後,worker可能並沒有完成重啟(等待正在執行的舊任務完成 才退出和新建),因此如果整個系統中只使用HUP信號挨個灰度各個機器,那麼很有可能出現全部worker離線的情況

接下來我們看看Gunicorn的重啟機制:

信號實質上掛在在Arbiter上,Arbiter相當於master,守護和管理worker的,管理各種信號,事實上它init的時候就給自己起好Master的名字了,列印的時候會打出來:

class Arbiter(object):n def __init__(self, app):n #一部分略n self.master_name = "Master" n def handle_hup(self):n """n HUP handling.n - Reload configurationn - Start the new worker processes with a new configurationn - Gracefully shutdown the old worker processesn """n self.log.info("Hang up: %s", self.master_name)n self.reload()n

這裡的函數文檔里寫了處理HUP信號的過程了,簡單的三行:

  1. 讀取配置
  2. 開啟新worker
  3. 優雅關閉舊Worker

reload函數的實現本身沒什麼複雜的,因為Gunicorn 是個Web容器,所以master裡面是沒有業務邏輯的,worker都是master fork出來的,fork是可以帶著文件描述符(自然也包括socket)過去的。這也是Gunicorn可以隨意增減worker的根源

master只負責兩件事情:

  • 拿著被Fork的worker的PID,以供關閉和處理
  • 1秒醒來一次,看看有沒有worker超時了需要被幹掉

while True:n sig = self.SIG_QUEUE.pop(0) if len(self.SIG_QUEUE) else Nonen if sig is None:n self.sleep()n self.murder_workers()n self.manage_workers()n continuen else:n #處理信號n

在sleep函數中,使用了select.select+timeout實現,和time.sleep的原理是一樣的,但不同之處在於select監聽了自己創建的一個PIPE,以供wakeup立即喚醒

總結

以上就介紹了Celery和Gunicorn的重啟機制差異。

從這兩者的設計來看,可以理解他們這樣實現的差異。

Celery是個分散式、非同步的任務隊列,任務信息以及排隊信息實質上是持久化在外部的MQ中的,例如RabbitMQ和redis,其中的持久化方式,這應該另外寫一篇《高級消息隊列協議AMQP介紹》,就不在這裡說了,對於Celery的Master和Worker來說,可以說是完全沒有狀態的。由Celery的部署方式也可以知道,近似於一個服務發現的框架,下線的Worker不會對整個分散式系統帶來任何影響。唯一的例外可能是Beat組件,作為Celery定時任務的節拍器,要做少許改造以適配分散式的架構,並且實現Send Once功能。

Gunicorn作為Python的Web容器之一,會接收用戶的請求,雖然我們通常都會使用nginx放在Gunicorn前方做反向代理,通常也可以使用nginx來做upstream offline、online的熱重啟,但那就不是一個層次的事情了

這裡回頭來再吐槽Golang

項目中使用到了Golang的一個Web框架,Golang在1.8中也已經支持Http.Server的熱關閉了,但是一是因為剛出不久(竟然現在才出),二是因為Golang的進程模型和Python大相近庭,go協程嘛,目前還沒有看到那個Web框架中真正實現Gunicorn類似的熱重啟。

Golang 在fcgi的操作應該就類似Python之於wsgi了。。我感覺我是選擇錯了一個web框架

也沒看見有人用syscall.Exec來用一下execve系統調用,Golang也沒看見有人用socket REUSE。。作為一個懶惰的人感覺很蛋疼。。。

先讓nginx大法做這件事情好了


推薦閱讀:

使用vs code進行Python編程,如何進行input輸入?
為什麼Sublime Text不支持Python交互?
Python中一個創建樹結構的方法。
Python 類組合(composition)和聚合(aggregation)
有哪些學習氛圍比較不錯的 Python 論壇?

TAG:Python |