android - Firestore 当离线设备上线时会发生什么？

Question

我正在查看 firestore，但该文档对 android 上的持久数据非常了解。我的问题是关于设备重新联机时将执行的操作。

假设我的在线数据量如此之低:

MyCollection
| ----------------------- MyDocument (empty)

如果我有两台设备与此模型同步但处于离线状态， 都写在 MyDocument 中，设备 A 创建了字段 id，值为 A，我的设备 B 也创建了字段 id，值为 >B.

设备A先上线，然后与Firestore同步，然后设备B上线，问题是字段id已经存在，并且有其他值。

Firestore 知道它是在后台自动完成的，将如何处理它？它是否有机会捕获冗余来解决自己的问题？

Answer 1

在这种情况下，Firestore 不做任何冲突解决。这意味着在整个流程完成后，来自设备 B 的写入将被存储。在数据库级别这是正确的，因为它无法知道您是否需要其他东西。

如果你想阻止设备 B 的写入，你必须确保这一点。您可以执行以下几项操作:

1. 在 transaction 中执行写入.
2. 使用security rules以确保设备 B 被拒绝。
3. 使用不允许冲突更新的数据模型。

将写入放入事务 是两者中最简单的。但是，如果客户端离线，它将失败，因为在这种情况下，客户端无法检查并发更新。

或者，您可以使用安全规则，当客户端数据到达服务器时，这些规则会在 Firebase 服务器上进行评估。如果您可以检测到来自设备 B 的写入无效/过时，则可以拒绝它。

一个相当简单的例子是在每个写操作中放置一个时间戳，然后拒绝新时间戳在数据库中的时间戳之前的写入。这可确保如果进行了更改，则会存储最后一次进行的更改(而不是最后一次返回联机)。

如您所见，这两个都是解决问题的重要方法。这就是为什么我的第一个建议是找到一个可以完全防止冲突的数据模型。通过避免冲突写入，您可以避免必须解决冲突。这样做的一个很好的例子是不让客户更新实际文档，而是让他们将他们的更改存储为单独的数据 fragment ，而不会覆盖任何内容。

MyCollection
| ---- MyDocument (empty)
| -------- Change from device A
| -------- Change from client B

现在，所发生事件的全部踪迹都存储在数据库中，每个客户都可以使用此信息根据您拥有的任何业务规则构建实际文档。

这在NoSQL数据库中其实是一种很常见的做法，尤其是在需要海量并发写入的项目中。通过防止写入冲突和使用仅追加数据模型，可扩展性得到极大提高。它也是许多(关系)数据库的“操作日志”文件背后使用的模型。通过保留所有操作的日志，他们可以从一开始就重建数据库。

在许多情况下，您还会偶尔存储文档状态的快照，以便更快地确定当前文档。这可以由随机客户端完成，也可以由受信任的进程完成，例如在您控制的服务器上或 Cloud Functions for Firebase。