假设我有一个由cron作业调用的Cloud Firebase函数，每次调用时都会产生30+个任务。
这些任务非常慢(平均每个任务 5 - 6 秒(，我无法直接在原始任务中处理它们，因为它会超时。
因此，解决方案是调用另一个"worker"函数，每个任务一次，以独立完成任务并将结果写入数据库。到目前为止，我能想到三种策略：
-
发布订阅消息。那将是惊人的，但似乎您只能从云函数中监听 pubsub 消息，而不能创建一个。求助于外部解决方案，例如拥有 GAE 实例，对我来说不是一个选择。
-
从第一个调用工作人员 http 触发的 Firebase Cloud Function。我认为这是行不通的，因为我需要等待所有调用的工作线程函数的响应，在它们完成并
send之后，我的原始函数将超时。 -
将任务追加到实时数据库列表，然后让每个数据库更改触发工作线程函数。之后，工作人员必须从队列中删除任务。这可能会起作用，但感觉一个简单的问题有很多活动部件。例如，如果工人扔了怎么办？需要另一个 cron 来"清理"数据库等。
想到的另一个解决方案是Firebase-queue，但其自述文件明确指出：
"火基地队列可能会继续有特定的用例， 但是，如果您正在寻找通用的可扩展队列 Firebase的系统，那么很可能建立在谷歌之上 Firebase 的云功能是理想的途径">
它没有得到官方支持，他们实际上是在说我们应该改用函数(这就是我正在尝试做的(。我对在生产中使用明天可能会被放弃的库(如果还没有的话(有点紧张，并希望避免走这条路。
从云函数发送发布/订阅消息
云函数在相当标准的 Node.js 环境中运行。考虑到 Node/NPM 生态系统的广度，你可以在 Cloud Functions 中做的事情非常广泛。
似乎您只能在云函数中监听 pubsub 消息，而不能创建一个
您可以使用用于发布/订阅的常规 Node.js 模块从云函数中发布新消息到发布/订阅主题。有关示例，请参阅云发布/订阅文档。
通过数据库写入从云函数触发新操作
这也是一种相当普遍的模式。我通常会让我的子进程/工作线程在将结果写回数据库的同时清理自己。这在我的简单场景中工作正常，但您的里程当然可能会有所不同。
如果您遇到具体的清理问题，请发布重现该问题的代码，我们可以看看使其更健壮的方法。