我在 Windows 上运行 Pyramid 应用程序，使用Waitress作为应用服务器，IIS 作为 Web 服务器（代理）。当我运行该应用程序时，它会在（看似）随机的时间内工作，然后才会停止。它可以持续几天，甚至几周，然后停止，让 IIS 抛出 502 错误。当它停止时，除了重新启动 Windows 之外，没有办法重新启动它。
这是一个小型应用程序，它使用 APScheduler 访问几个 API 以在 eBay/Amazon 之间同步库存。我不完全确定是什么导致了这个问题，因为日志中没有显示错误。我有一个旧版本的应用程序正在运行（没有 APScheduler）并且我没有遇到这个问题，所以我假设它与 APScheduler 有关。
有没有其他人经历过这个？
首先让我说我自己还没有使用过 APScheduler，并且对在 Windows 和 IIS 上运行 Python 服务器（或其他任何东西）几乎一无所知。
所以我只能在这里猜测，但很明显你的问题在某种程度上与 APScheduler 有关。我可以想象 APScheduler 用于您的后台任务的线程出现问题，并且由于 GIL（Python 中的全局解释器锁），挂起的线程会导致您的整个应用程序崩溃。例如，当您的线程遇到某种竞争条件时，可能会发生这种情况。也许在前一次迭代完成处理之前开始处理。或者你得到一个非常大的积压，这会在处理开始时导致问题。
无论如何，我认为任务队列更适合 Web 应用程序的后台处理，因为它们是独立运行的，并且脱离了 Web 服务器的上下文。您可以在某个用户操作触发后立即安排任务，一旦有工作人员可用，它就会被处理，并且不会推迟到某个时间点。
我建议尝试一下Celery，但也有其他可用的解决方案，其中许多基于 Redis。
Celery 非常强大，并且具有周期性任务和 crontab 样式计划等高级功能 - 所以您现在可以使用它来执行您正在使用 APScheduler 执行的操作。
这看起来对在 Windows 下设置 Celery 很有帮助：http: //mrtn.me/blog/2012/07/04/django-on-windows-run-celery-as-a-windows-service/
这也可能有帮助:
如何创建 Celery Windows 服务？
注意：我自己没有尝试过任何这些，因为如果我有选择的话，我会使用 Linux。
也可能让 APScheduler 正常工作，但我认为使用 Celery 会容易得多，因为如果工作人员出现问题，您将能够比后台线程中出现的问题更容易地调试它。Celery 还可以配置为在出现错误时自动向您发送电子邮件。