基于多進(jìn)程中APScheduler重復(fù)運行的解決方法

更新時間：2019年07月22日 08:40:23 作者：猛禽

今天小編就為大家分享一篇基于多進(jìn)程中APScheduler重復(fù)運行的解決方法，具有很好的價值，希望對大家有所幫助。一起跟隨小編過來看看吧

問題

在一個python web應(yīng)用中需要定時執(zhí)行一些任務(wù)，所以用了APScheduler這個庫。又因為是用flask這個web框架，所以用了flask-apscheduler這個插件（本質(zhì)上與直接用APScheduler一樣，這里不作區(qū)分）。

在開發(fā)中直接測試運行是沒有問題的，但是用gunicorn部署以后發(fā)生了重復(fù)運行的問題：

每個任務(wù)在時間到的時刻會同時執(zhí)行好幾遍。

注意了一下重復(fù)的數(shù)量，恰恰是gunicorn里配置的worker進(jìn)程數(shù)量，顯然是每個worker進(jìn)程都啟動了一份scheduler造成。

解決

可以想到的方案有幾個：

用--preload啟動gunicorn，確保scheduler只在loader的時候創(chuàng)建一次

另外創(chuàng)建一個單獨的定時任務(wù)項目，單獨以一個進(jìn)程運行

用全局鎖確保scheduler只運行一次

經(jīng)過實踐，只有第三個方案比較好。

preload的問題：

雖然這樣可以使用scheduler創(chuàng)建代碼只執(zhí)行一次，但是問題也在于它只執(zhí)行一次，重新部署以后如果用kill -HUP重啟gunicorn，它并不會重啟，甚至整個項目都不會更新。這是preload的副作用，除非重寫部署腳本，完全重啟應(yīng)用。

單獨進(jìn)程的問題：

也是因為部署麻煩，需要多一套部署方案，雖然用Docker會比較方便，但仍然不喜歡，而且同時維護(hù)兩個項目也多出很多不必要的事情。

全局鎖是一個較好的方案，但問題在于找一個合適的鎖。

python自帶的多進(jìn)程多線程鎖方案都需要一個共享變量來維護(hù)，但是因為worker進(jìn)程是被gunicorn的主進(jìn)程啟動的，并不方便自己維護(hù)，所以需要一個系統(tǒng)級的鎖。

在Stackoverflow上看到有人是用了一個socket端口來做鎖實現(xiàn)這個方案，但是我也不喜歡這樣浪費一個寶貴的端口資源。不過這倒給了我一個啟發(fā)：

可以用文件鎖！

于是有了這個解決方案：

import atexit
import fcntl
from flask_apscheduler import APScheduler

def init(app):
 f = open("scheduler.lock", "wb")
 try:
  fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
  scheduler = APScheduler()
  scheduler.init_app(app)
  scheduler.start()
 except:
  pass
 def unlock():
  fcntl.flock(f, fcntl.LOCK_UN)
  f.close()
 atexit.register(unlock)

原理

init函數(shù)為flask項目初始化所調(diào)用，這里為scheduler模塊的初始化部分。

首先打開（或創(chuàng)建）一個scheduler.lock文件，并加上非阻塞互斥鎖。成功后創(chuàng)建scheduler并啟動。

如果加文件鎖失敗，說明scheduler已經(jīng)創(chuàng)建，就略過創(chuàng)建scheduler的部分。

最后注冊一個退出事件，如果這個flask項目退出，則解鎖并關(guān)閉scheduler.lock文件的鎖。

以上這篇基于多進(jìn)程中APScheduler重復(fù)運行的解決方法就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

您可能感興趣的文章: