轉自：http://blog.csdn.net/raptor/article/details/69218271
問題
在一個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文件的鎖。