如何避免Heroku「重定位dyno至新服务器」操作导致调度器失效

首先明确基础事实：不存在可完全阻止Heroku执行dyno重定位的用户侧可行方案。dyno重定位是Heroku平台基础设施层的调度逻辑，属于平台固有运维操作，用户没有权限干预底层节点的资源分配、迁移流程。
你遇到的“重定位后调度器停止工作”的问题，本质是对重定位的状态同步规则存在误解：dyno重定位不是将当前运行的实例整体打包迁移到新服务器，而是在目标新节点上重新启动同版本的应用部署实例，过程中不会复制旧节点上的本地临时文件、手动修改的运行文件、未纳入部署流程定义的临时进程——这就是手动配置的调度器会在重定位后失效的核心原因。

可落地的问题解决思路：

• 将调度器的启动逻辑完全纳入应用部署流程
  不要在dyno启动后通过shell登录手动创建调度脚本、启动调度进程，而是把调度器的执行命令、依赖配置全部写进项目的Procfile，随代码一起打包到应用版本中。无论dyno被重定位到哪个节点，新节点启动的都是同一份标准部署包，会自动拉起定义好的调度器进程，不会出现状态丢失的问题。
• 避免依赖dyno本地临时存储存放调度相关文件
  所有调度脚本、配置参数都要保存在应用代码目录、Heroku配置环境变量或正式持久化存储中，不要存放在dyno节点的临时目录、用户home目录这类重定位后会被清空的路径下。
• 选择对应版本的dyno减少非必要的重定位频次
  免费版、基础版dyno本身就存在固定周期的强制回收、休眠机制，重定位是这类回收流程的常见环节，状态丢失概率极高。如果需要降低重定位的触发频率，可以选用性能级dyno，这类实例的回收、重定位触发间隔更长，但依然无法实现100%阻止迁移的效果。
• 排查调度器的配置有效性
  如果使用平台自带的调度类插件，需要确认任务的执行路径是绑定应用代码包内的固定路径，不要引用手动在dyno节点上创建的临时脚本路径——这类路径在重定位后会完全消失，必然导致调度任务失效。

需要明确的操作边界：任何第三方宣传的“锁定dyno节点、阻止重定位”的方案都不被Heroku官方支持，这类操作通常依赖平台未公开的接口，随时可能因为平台版本迭代失效，甚至触发账号使用规则风控。

内容的提问来源于stack exchange，提问作者Lila