基于多進程中APScheduler重復運行怎么辦

這篇文章主要介紹基于多進程中APScheduler重復運行怎么辦，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

問題

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

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

每個任務在時間到的時刻會同時執行好幾遍。

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

解決

可以想到的方案有幾個：

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

另外創建一個單獨的定時任務項目，單獨以一個進程運行

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

經過實踐，只有第三個方案比較好。

preload的問題：

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

單獨進程的問題：

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

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

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

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

可以用文件鎖！

于是有了這個解決方案：

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函數為flask項目初始化所調用，這里為scheduler模塊的初始化部分。

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

如果加文件鎖失敗，說明scheduler已經創建，就略過創建scheduler的部分。

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

以上是“基于多進程中APScheduler重復運行怎么辦”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！