### 防止 django-apscheduler 调度器重复启动 为了防止 `django-apscheduler` 调度器在 Django 应用中多次启动，可以采用文件锁机制来确保只有一个实例能够成功启动调度器。具体方法是在应用初始化时创建并尝试获取一个独占锁，如果无法获得则说明已经有其他进程持有该锁，从而避免再次启动调度器。 ```python import fcntl import atexit def initscheduler(scheduler): lock_file = "scheduler.lock" with open(lock_file, "w") as f: try: # 尝试加锁 fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB) # 注册事件监听以及启动调度器 register_events(scheduler) scheduler.start() # 设置退出时解锁操作 def unlock(): fcntl.flock(f, fcntl.LOCK_UN) atexit.register(unlock) except IOError: print("Another instance is already running.") ``` 此代码片段通过打开名为 `"scheduler.lock"` 的文件，并试图对该文件加上非阻塞模式下的独占锁定 (`LOCK_EX | LOCK_NB`) 来实现单例控制逻辑[^2]。当有多个工作线程或者服务器节点存在时，只有第一个成功取得锁的工作单元会执行后续的调度器配置与启动动作；其余未能拿到锁者将会跳过这部分流程而不会干扰到已经存在的调度服务。 另外，在生产环境中部署 Django 应用时还需要注意以下几点： - **多进程环境**：对于使用 gunicorn 或 uWSGI 这样的 WSGI 容器来说，默认情况下可能会开启多个 worker 进程。这可能导致即使有了上述措施仍然会有不同 worker 启动相同的定时任务的情况发生。因此建议将此类任务放在专门的任务队列里处理，比如 Celery beat 结合 Redis/Memcached 作为 broker。 - **持久化存储**：考虑到系统的高可用性和容灾能力，推荐使用支持分布式事务的数据源保存作业状态信息，如 MySQL/PostgreSQL 数据库中的表结构形式替代内存型 Job Store，这样可以在重启后继续未完成的任务计划而不丢失任何进度。 #### 关于数据库连接超时问题 值得注意的是，长时间运行的应用程序可能遇到数据库连接断开的问题（即所谓的“MySQL server has gone away”错误）。针对这个问题，可以通过调整 MySQL 和应用程序端的相关参数设置加以缓解，例如增大 wait_timeout 值、启用自动重连功能等[^1]。