問題

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

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

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

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

解決

可以想到的方案有幾個：

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

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

用全局鎖確保scheduler只運(yùn)行一次

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

preload的問題：

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

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

也是因?yàn)椴渴鹇闊枰嘁惶撞渴鸱桨?，雖然用Docker會比較方便，但仍然不喜歡，而且同時(shí)維護(hù)兩個項(xiàng)目也多出很多不必要的事情。

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

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

在Stackoverflow上看到有人是用了一個socket端口來做鎖實(shí)現(xiàn)這個方案，但是我也不喜歡這樣浪費(fèi)一個寶貴的端口資源。不過這倒給了我一個啟發(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項(xiàng)目初始化所調(diào)用，這里為scheduler模塊的初始化部分。

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

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

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

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

最新評論