英文:
Performing go routines in background
问题
我是你的中文翻译助手，以下是你要翻译的内容：
我刚开始使用Go语言，在我的Heroku应用中使用了Go协程（go routines），这些协程可能会运行很长时间（最多7分钟），而且不能被中断。
我发现自动扩展器有时会关闭正在运行协程的Heroku dyno。我需要一种独立于dynos运行这个协程的方法，以确保它不会被关闭。我阅读了一些文章，但仍然不明白如何在后台工作器（background worker）中执行Go协程。很难让我相信我是唯一一个遇到这个问题的人。
我的Go协程使用了Redis数据库。
请问有人可以给我指点一个在Heroku上设置Go后台工作器的示例，并告诉我如何将我的Go协程发送到该工作器吗？
非常感谢！
英文:
I am new to Go and I am using go routines in my app in Heroku, which are long (up to 7 minutes), and cannot be interrupted.
I saw that the auto scaler sometimes kills the Heroku dyno which is running the routine. I need a way of running this routine independently from the dynos so I know that it will not get shutdown. I read articles and still don't understand how to perform a go routine in a background worker. It is hard for me to believe I am the only one experiencing this.
My go routines use my redis database.
Could someone please point me to an example of how to setup a background worker in heroku for go and how to send my go routine to that worker?
Thank you very much
答案1
得分: 1
如果您不想在dyno上运行工作代码，那么您需要使用Heroku之外的其他提供商，比如Amazon AWS、Digital Ocean、Linode等。
话虽如此，您应该设计您的工作程序，特别是那些至关重要的程序，以便能够从关闭中恢复。要么能够继续上次的工作，要么重新开始。Heroku的dyno管理器每天至少重启一次dyno，但其他云提供商也可能偶尔重启他们的虚拟实例，可能不是每天一次，但仍然可能发生。即使您决定在您控制的物理机器上部署工作程序并且永不关闭，也无法防止硬件故障或停电等问题的发生。
如果您的工作程序需要执行某个任务直到完成，您需要让它们意识到可能的关闭，并优雅地处理这种情况。永远不要依赖于机器（无论是物理的还是虚拟的）在工作程序执行任务时一直运行。
例如，如果您使用Heroku，请使用worker dyno，并让您的工作程序监听SIGTERM信号，在工作程序接收到此信号后...
> 应用程序进程有30秒的时间来进行干净的关闭（理想情况下，它们会更快完成）。在此期间，它们应停止接受新的请求或作业，并尝试完成当前的请求，或将作业放回队列以供其他工作程序处理。如果在该时间段之后仍有进程存在，dyno管理器将使用SIGKILL强制终止它们。
...在这里继续阅读。
但请记住，正如我之前提到的，如果出现故障并且Heroku崩溃，这种情况偶尔会发生，您的工作程序甚至没有这30秒的时间来清理。
英文:
> I need a way of running this routine independently from the dynos so I
> know that it will not get shutdown.
If you don't want to run your worker code on a dyno then you'll need to use a different provider from Heroku, like Amazon AWS, Digital Ocean, Linode etc.
Having said that, you should design your workers, especially those that are mission critical, to be able to recover from a shutdown. Either to be able to continue where they left off or to start over. Heroku's dyno manager restarts the dynos at least once a day but I wouldn't be surprised if the other cloud providers also restart their virtual instances once in a while, probably not once a day but still... And even if you decide to deploy your workers on a physical machine that you control and never turn off, you cannot prevent things like hardware failure or power outage from happening.
If your workers need to perform some task till it's done you need to make them be aware of possible shutdowns and have them handle such scenarios gracefully. Do not ever rely on a machine, physical or virtual, to keep running while your worker is doing it's job.
For example if you're on Heroku, use a worker dyno and make your worker listen for the SIGTERM signal, after your worker receives such a signal...
> The application processes have 30 seconds to shut down cleanly
> (ideally, they will do so more quickly than that). During this time
> they should stop accepting new requests or jobs and attempt to finish
> their current requests, or put jobs back on the queue for other worker
> processes to handle. If any processes remain after that time period,
> the dyno manager will terminate them forcefully with SIGKILL.
... continue reading here.
But keep in mind, as I mentioned earlier, if there is an outage and Heroku goes down, which is something that happens from time to time, your worker won't even have those 30 seconds to clean up.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论