与 Firebase 实时数据库的强一致性

Question

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

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

场景 1

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

场景 1 的逻辑似乎工作正常，但是，我们开始怀疑 Firebase 是否真的提供强一致性，以及我们是否可以确定 Server B 何时获取 items/:itemID来自 Firebase，文档肯定存在。

场景 2

1. 服务器 A 将 item 文档写入 /items 并等待 .set() 操作通过。
2. 服务器 A 通过 POST /processItem/:itemID 调用 服务器 B
3. 服务器 B 获取 items/:itemID 并开始处理
4. 处理后，服务器 B 写入 item.processedAt = <timestamp>

这可能会更加“危险”，因为 服务器 A 可能会在 child_added 事件触发之前调用 服务器 B。

这两种情况都安全吗？

Answer 1

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

场景 1 是完全安全的。因为只有在firebase完全写入数据时才会调用云函数。所以，在场景 1 中你绝对是安全的。

对于场景 2。你可以这样走。

• 服务器 A 将 item 文档写入 /items
• 服务器 A waits for the callback 从 firebase 完成。
• 服务器 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 可能会有所帮助。