android - Firestore 离线设备上线时会发生什么？
问题描述
我正在查看 firestore，但该文档对 android 上的持久数据非常了解。我的问题是关于设备重新联机时将发生的操作。
让我们想象一下，我的在线数据如此之低：
MyCollection
| ----------------------- MyDocument (empty)
如果我有两个与此模型同步但处于脱机状态的设备，都在 MyDocument 中写入，则该设备 A 创建了id带有 value的字段，A而我的设备 B 也创建了一个id带有 value的字段B。
设备 A 首先在线返回，然后与 Firestore 同步，然后设备 B 在线返回，问题该字段id已存在另一个值。
知道它是在后台自动完成的，Firestore 将如何处理？它是否有机会抓住冗余来解决问题？
解决方案
在这种情况下，Firestore 不会进行任何冲突解决。这意味着在整个流程完成后，来自设备 B 的写入将被存储。在数据库级别这是正确的，因为它无法知道您是否想要其他东西。
如果您想阻止来自设备 B 的写入，则必须确保这一点。您可以做几件事：
将写入放入事务中是两者中最简单的。但是，如果客户端离线，它将失败，因为在这种情况下客户端无法检查并发更新。
或者，您可以使用安全规则，当客户端数据到达服务器时，这些规则会在 Firebase 服务器上进行评估。如果您可以检测到来自设备 B 的写入无效/过时的事实，您可以拒绝它。
一个相当简单的情况是在每个写入操作中放置一个时间戳，然后拒绝新时间戳在数据库中的时间戳之前的写入。这可确保如果进行了更改，则会存储最后一个所做的更改（而不是最后一个重新联机的更改）。
正如您所看到的，这两个都是解决问题的重要方法。这就是为什么我的第一个建议是找到一个完全防止冲突的数据模型。通过避免写入冲突，您可以避免必须解决冲突。这样做的一个很好的例子是不让客户端更新实际文档，而是让他们将他们的更改存储为单独的数据片段，而不会覆盖任何内容。
MyCollection
| ---- MyDocument (empty)
| -------- Change from device A
| -------- Change from client B
现在所有发生的事情都存储在数据库中，每个客户都可以根据您拥有的任何业务规则使用这些信息来构建实际文档。
这实际上是 NoSQL 数据库中相当常见的方法，尤其是在需要大量并发写入的项目中。通过防止写入冲突和使用仅附加数据模型，可扩展性得到极大提高。它也是许多（关系）数据库的“操作日志”文件背后使用的模型。通过保留所有操作的日志，他们可以从一开始就重建数据库。
在许多情况下，您还会偶尔存储文档状态的快照，以便更快地确定当前文档。这可以由随机客户端完成，也可以由受信任的进程完成，例如您控制的服务器或 Cloud Functions for Firebase。