与Firebase实时数据库保持高度一致性

Question

Firebase实时数据库是否提供强一致性？

在某些情况下，我们将Firebase实时数据库用作队列：

场景1

1. 移动客户端将item文档写入/items
2. 服务器A （云功能）收听/items，并通过POST /processItem/:itemID呼叫服务器B
3. 服务器B 获取items/:item并开始处理
4. 处理后，服务器B 写入item.processedAt = <timestamp>

场景1的逻辑似乎可以正常工作，但是，我们开始怀疑Firebase是否确实提供了 strong一致性，以及我们是否可以确定服务器B 何时获取{{1 }}来自Firebase，肯定是 文档。

场景2

1. 服务器A 将items/:itemID文档写入item
2. 服务器A 通过/items
呼叫服务器B
3. 服务器B 获取POST /processItem/:itemID并开始处理
4. 处理后，服务器B 写入items/:itemID

这可能更加“危险”，因为甚至在item.processedAt = <timestamp>事件触发之前，服务器A 可能会调用服务器B 。

这两种情况都安全吗？

Answer 1

恕我直言，这两种情况都是安全的。

方案1是完全安全的。因为仅在firebase已完全写入数据时才调用云功能。因此，在方案1中您绝对是安全的。

对于方案2。您可以按照这种方式进行。

• 服务器A将item文档写入/items
• 从Firebase完成的服务器waits for the callback。
• 服务器A通过POST /processItem/:itemID呼叫服务器B
• 服务器B获取items/:itemID并开始处理
• 处理后，服务器B写入item.processedAt = <timestamp>

Answer 2

Bhavin Panara是正确的。按照您所描述的方式，这两种情况都是“安全的”。确认写入后，实时数据库保证所有后续读取都将看到已确认写入的结果。对于通过写入触发云功能的情况也是如此。

您已经注意到，侦听器是异步更新的，因此，在一段时间内，监听某个位置的客户端可能不会更新有关写操作的信息。

请注意，即使使用非常一致的数据库，仍然可能存在竞争条件。请考虑以下情形：

场景3

• 移动客户端在/items/item1上创建数据
• 服务器A（云功能）侦听/ items并通过POST / processItem /：itemID调用服务器B
• 移动客户端删除/items/item1上的数据
• 服务器B收到来自服务器A的请求并获取/items/item1，但该项已删除。

在这种情况下，退回到transactions可能会有所帮助。