避免在 Firebase 中添加子项/更改子项的无限循环

Question

我正在尝试创建一个工作进程来侦听 Firebase 以了解对特定集合的添加/更改。在任何一种情况下，都应该运行一个进程，该进程最终会根据它在那里找到的内容将一些额外的数据写回集合。我遇到的问题是这会导致无限循环，因为 child_changed 将再次触发回调，因为我正在更改它正在侦听的同一棵树中的模型。此外，在第一次通过 child_add 触发 child_changed 时存在初始重复工作。

我想出的唯一解决方案是以某种方式将数据放入 Firebase，表明不应发生更新（is_dirty: false，或类似的东西）。我对那个解决方案不是特别满意，因为这要求客户端在添加/更改应该触发服务器处理的内容时参与翻转标志或其他内容。我希望他们不要那么耦合。我当然喜欢维护某种缓存集合以比较更改的想法，因为这会复制大量数据。

我还考虑在更新之前以某种方式使用off（之后将其重新打开），但我担心这会导致我错过可能在那个时间窗口内发生的更改。也许这是交易的情况？

这里的最佳做法是什么？目前，我的代码如下所示：

collectionRef.on('child_added', processModel);
collectionRef.on('child_changed', processModel);

var processModel = function (modelSnapshot) {
  // do some stuff that updates model
}

Answer 1

您的主进程和工作进程（默认情况下）绑定非常松散 - 仅通过一个修改数据而另一个被告知数据危险已更改的事实链接。

添加队列或信号量是一种更紧密地绑定它们的方法。

但是，我更喜欢的模型通常是将它们绑定得更松...

不要考虑事件，而要考虑数据的状态。

设计您的工作进程以获取脏数据库并使其干净。然后将 'on update' 调用视为一种优化 - 有效地为您的工作进程提供关于数据库的哪个部分可能需要清理的“线索”。

使用这种模式意味着没有“无限更新”问题，因为一旦清理，就不会执行额外的更新，而且它的可扩展性非常强 - 您可以让多个工作进程在数据库的不同部分工作，或者以不同的方式清理不同的元素。

不利的一面是，必须将数据结构化以在“状态”下工作，并且使用数据的程序必须在设计时考虑到它们读取的数据可能是脏的。虽然如果这很重要，我会让客户端读取数据以检查它是否脏并在继续之前触发清理......

Answer 2

[在不了解您的用例的情况下，回答这个问题有点困难，但我会提供一些一般性的思考。]

请务必记住，Firebase 会同步数据，而不是“事件”。因此，每次您重新启动工作进程时，它都会为所有现有数据获取 child_added 事件。

此外，如果您的工作进程已经关闭了一个小时并且用户对模型中的项目进行了一系列更改，那么当您的工作进程再次启动时，它仍然会得到一堆 child_added 事件，而不是离线更改的单个 child_changed 事件。

所以你通常想做两件事之一：

1. 在 Firebase 中存储一个“工作队列”，让您的工作进程从队列中抓取项目，处理它们，然后丢弃它们（或将它们标记为已完成或将它们移动到其他位置或其他任何地方）。

2. 在每个模型对象中存储一个“状态”，指示它所处的状态以指示需要进行什么处理（类似于您的肮脏想法）。用户可能将一个项目添加为“初始”，您的工作进程将拾取它，进行处理，然后以“已处理”或类似的状态将其写回。如果客户端进行了修改，它会将其标记为“脏”，并且您的工作进程将再次进行修改并将状态更新为“已处理”

如果您采用其中一种方法，您的工作进程应该很容易知道它需要处理哪些项目，并且它应该优雅地处理重新启动/停机等，正确地从中断的地方“接起”。