node.js - 我什么时候需要在 Heroku 中使用工作进程

Question

我有一个 Node.js 应用程序，其中有一小部分用户，当前使用单个 Web 进程构建。我正在考虑添加一个保存后触发器，当将记录添加到我的表之一时将调用该触发器。当执行保存触发器后，我想对外部API执行大量IO操作。 IO 操作的数量取决于记录上数组列中的元素数量。因此，在将每条记录保存到这个特定表中后，我可能会执行大量异步操作。

我考虑过按照 Worker Dynos, Background Jobs and Queueing 中的建议将这项工作移至后台作业。本文给出的经验法则是将耗时超过 500 毫秒的任务移至后台作业。但是，在使用 RabbitMQ ( Asynchronous Web-Worker Model Using RabbitMQ in Node ) 完成示例之后，我不相信值得花时间来设置所有内容。

所以，我的问题是:

• 对于并发用户数量有限的应用，是否可以在网络进程中保留长时间运行的函数？
• 如果我最终决定将这项工作发送到后台作业，那么更改我的保存后触发器似乎并不那么困难。我是不是漏掉了什么？
• 有没有比实现消息队列更容易做到这一点的方法？

Answer 1

For an app with a limited amount of concurrent users, is it ok to leave a long-running function in a web process?

这更多的是一个偏好问题，而不是任何问题。

总的来说，我说不 - 这不好......但这是基于构建在heroku工作人员中运行的rabbitmq服务的经验，并且不认为这是一件困难的事情。

经过一点练习，您可能会发现这是更简单的解决方案，就像我一样(它允许更简单的代码和更健壮的代码，因为它将网络与后台处理器分开 - 允许每个都在不知道的情况下运行直接彼此)

If I eventually decide to send this work to a background job it doesn't seem like it would be that hard to change my after save trigger. Am I missing something?

你是不是漏掉了什么？不是真的

只要您以结构良好且模块化的方式编写当前的 Web 进程内代码，将其移动到后台进程通常并不是什么大问题

人们因必须将代码移至后台而产生的大部分 panic 来自于将代码与 HTTP 请求/响应过程紧密耦合(我从个人经验中知道这会是多么痛苦)

Is there a way to do this that is easier than implementing a message queue?

分布式计算和后台处理有很多选择。我个人喜欢 RabbitMQ 及其使用的消息传递模式。

我建议您尝试一下，看看它是否适合您。

其他选项包括在其之上带有发布/订阅库的 Redis，使用直接 HTTP API 调用另一个 Web 服务器，或者仅在后台进程中使用计时器以给定频率检查数据库表并让代码运行基于根据它找到的数据。

附:如果您想更深入地了解带有 Node 的 RMQ，您可能会对我的 RabbitMQ For Developers 类(class)感兴趣:http://rabbitmq4devs.com