假设我有一个由定时作业调用的Cloud Firebase Function，每次被调用时会产生30多个任务。
这些任务相当缓慢（平均每个任务需要5-6秒），我不能直接在原始函数中处理它们，否则会超时。
因此，解决方案是调用另一个“工作”函数，每个任务调用一次，独立完成任务并将结果写入数据库。到目前为止，我能想到三种策略：
这些任务相当缓慢（平均每个任务需要5-6秒），我不能直接在原始函数中处理它们，否则会超时。
因此，解决方案是调用另一个“工作”函数，每个任务调用一次，独立完成任务并将结果写入数据库。到目前为止，我能想到三种策略：
发布订阅消息。那将是很棒的，但似乎您只能从Cloud Function内部监听pubsub消息，而不能创建一个。我不想使用外部解决方案，比如拥有GAE实例。
从第一个函数调用http触发的Firebase Cloud Function。我认为这行不通，因为我需要等待所有被调用的工作函数完成并发送后的响应，否则我的原始Function会超时。
将任务附加到实时数据库列表，然后由每个数据库更改触发工作函数。工人必须随后从队列中删除任务。那可能会起作用，但感觉有很多移动部分来解决一个简单的问题。例如，如果工人抛出异常怎么办？另一个计划任务来“清理”数据库将是必要的等等。
另一个想到的解决方案是firebase-queue，但它的README明确指出：
“firebase-queue”可能仍然存在特定的用例，但如果您正在寻找Firebase的通用、可扩展的队列系统，那么在Google Cloud Functions for Firebase之上构建是最理想的路线。”这并不是官方支持的，他们实际上是在说我们应该使用Functions（这也是我正在尝试做的）。我有点担心在生产环境中使用可能明天就被放弃的库（如果它还没有被放弃），并希望避免走这条路。”