Django部署Heroku后如何让APScheduler最新预测值在浏览器展示

前置必备调整：首先要把APScheduler生成的最新预测值持久化到web服务可访问的公共存储介质中（比如Django对接的PostgreSQL数据库、独立部署的Redis实例），别只把结果输出到服务控制台、或是存在调度器进程的本地内存里。Heroku上跑APScheduler的worker dyno和处理前端请求的web dyno是完全隔离的独立实例，内存空间不互通，只存在本地内存/控制台的内容，web层根本读不到。

方案1：前端定时轮询最新数据接口 #

• 实现逻辑：
  1. 后端新增一个轻量查询接口，从公共存储里读取最新的预测值、对应生成时间戳返回给前端。
  2. 前端页面设置固定的轮询间隔，定时请求这个查询接口，将返回的时间戳和当前页面展示内容的时间戳做比对，如果不一致就直接替换页面上的预测内容。
• 方案优势：
  • 上手最快，几乎没有额外的依赖成本，和Heroku的运行环境完全兼容，基本不会出现兼容性问题。
  • 可以灵活调整轮询频率，完美匹配APScheduler的运行周期：比如调度器每6小时跑一次预测，前端设置5-10分钟的轮询间隔，既不会给服务带来过大的请求压力，也能保证新值生成后短时间内同步到前端。
• 优化细节：可以在接口返回中增加简单的校验签名，避免接口被恶意频繁调用。

方案2：SSE（服务器发送事件）实现服务端主动推送 #

• 实现逻辑：
  1. 前端页面通过EventSource对象和后端建立SSE长连接，指向专门的消息推送接口。
  2. APScheduler生成新的预测值后，除了将值存入公共存储，还通过公共的消息中转介质（比如Redis的pub/sub频道）给web dyno发更新通知。
  3. web dyno收到更新通知后，从公共存储读取最新的预测值，通过保持的SSE连接推送给所有在线的前端页面，前端收到消息后直接替换页面展示内容。
• 方案优势：
  • 相比定时轮询，大幅减少无效的请求次数，仅需保持单向的HTTP长连接即可实现实时推送，落地难度远低于WebSocket。
  • Heroku的默认HTTP路由栈完全支持SSE协议，不需要额外调整网络配置。
• 适配Heroku的注意点：
  • 需要在前端添加SSE断线自动重连逻辑，应对Heroku的空闲连接超时回收机制，避免连接断开后无法收到后续推送。
  • 不要将SSE的消息监听逻辑直接绑定到APScheduler所在的worker dyno上，否则和前端的连接、运行调度器的进程完全隔离，根本无法触发推送。

方案3：WebSocket双向实时通信 #

• 实现逻辑：
  1. 基于Django Channels等WebSocket实现搭建实时通信通道，前端和web dyno建立WebSocket连接。
  2. APScheduler生成新预测值后，同样通过Redis等带pub/sub能力的公共中间件发布更新事件，所有建立了WebSocket服务的web dyno收到事件后，将最新预测值推送给连接在自身上的所有前端客户端。
• 适用场景：如果后续还需要增加用户和页面的实时交互需求（比如用户在前端手动触发模型训练、实时查看训练进度），可以选择这个方案。
• 适配Heroku的注意点：
  • 需要搭配ASGI服务运行，确保服务绑定的端口和Heroku分配的动态端口一致，避免路由无法访问。
  • 相比SSE，WebSocket的实现复杂度、资源占用都更高，如果只是为了单向推送预测值，有点大材小用。

内容的提问来源于stack exchange，提问作者Mohammad Saad Hassan