Firestore 离线设备上线时会发生什么? [英] Firestore what happens when an offline device goes online?
问题描述
我正在查看 firestore，但该文档对 android 上的持久数据非常了解.我的问题是关于设备重新联机时将发生的操作.
I'm looking at firestore but the doc is very light on persistent data on android. My question is about the actions that will take place when the device comes back online.
让我们想象一下，我的在线数据很少:
Let's imagine that I have this low of data online:
MyCollection
| ----------------------- MyDocument (empty)
如果我有两台设备与此模型同步但处于离线状态，都写在 MyDocument 中，设备 A 创建了字段 id 值为 A 并且我的设备 B 也创建了字段 id 值为 >B.
If I have two devices that synchronize with this model but are offline,
both write in MyDocument, that device A created the field id with value A and that my device B also creates a fieldid with value B.
设备 A 首先在线返回，然后与 Firestore 同步，然后设备 B 返回在线，问题 id 字段已存在另一个值.
Devices A returns first online and then synchronizes with Firestore then device B returns online, problem the field id already exists with another value.
Firestore 知道它是在后台自动完成的，将如何处理?它是否有机会捕捉冗余来解决问题?
How will Firestore handle this knowing that it's done in the background automatically? Does it have a chance to catch redundancies to fix itself the problem?
推荐答案
Firestore 在这种情况下不做任何冲突解决.这意味着在整个流程完成后，来自设备 B 的写入将是存储的.在数据库级别这是正确的，因为它无法知道您是否想要其他东西.
Firestore does not do any conflict resolution in this case. This means that after the entire flow is done, the write from device B will be the one stored. On a database level this is correct, since it has no way to know whether you wanted something else.
如果您想阻止设备 B 的写入，则必须确保这一点.您可以执行以下操作:
If you want to prevent the write from device B, you will have to ensure this. There are a few things you can do:
- Perform the writes in a transaction.
- Use security rules to ensure device B gets rejected.
- Use a data model that doesn't allow conflicting updates.
将写入写入事务是两者中最简单的.但是，如果客户端离线，它将失败，因为在这种情况下客户端无法检查并发更新.
Putting the write in a transaction is the simplest of the two. However it will fail if the client is offline, since the client in that case can't check for concurrent updates.
或者，您可以使用安全规则，当客户端数据到达服务器时，会在 Firebase 服务器上评估这些规则.如果您可以检测到来自设备 B 的写入无效/已过时的事实，您可以拒绝它.
Alternatively you can use security rules, which are evaluated on the Firebase servers when the client data reaches the server. If you can detect the fact that the write from device B is invalid/obsolete, you can reject it.
一个相当简单的例子是在每个写入操作中放置一个时间戳，然后拒绝新时间戳在数据库中的时间戳之前的写入.这可确保在进行更改时，会存储最后所做的更改(而不是最后一次重新联机).
A fairly simple case of this is putting a timestamp in every write operation, and then rejecting writes where the new timestamp is before the one in the database. This ensures that if a change is made, the last one that was made is stored (instead of the last one to come back online).
如您所见，这两个都是解决问题的重要解决方案.这就是为什么我的第一个建议是找到一个完全防止冲突的数据模型.通过避免冲突写入，您可以避免必须解决冲突.这样做的一个很好的例子是不让客户端更新实际文档，而是让它们将更改存储为单独的数据块，而不会覆盖任何内容.
As you can see both of these are non-trivial solutions to the problem. That's why my first recommendation would be to find a data model that prevent conflicts altogether. By avoiding conflicting writes, you can prevent having to solve the conflicts. A good example of doing this is by not letting the clients update the actual document, but having them store their changes as separate pieces of data without either of them overwriting anything.
MyCollection
| ---- MyDocument (empty)
| -------- Change from device A
| -------- Change from client B
现在所有发生的事情的轨迹都存储在数据库中，每个客户都可以使用此信息根据您拥有的任何业务规则构建实际文档.
Now the entire trail of what happened is stored in the database, and each client can use this information to construct the actual document based on whatever business rules you have.
这实际上是 NoSQL 数据库中一种非常常见的方法，尤其是在需要大量并发写入的项目中.通过防止写入冲突并使用仅附加数据模型，可扩展性得到了极大的提高.它也是许多(关系)数据库的操作日志"文件背后使用的模型.通过记录所有操作的日志，他们可以从头开始重建数据库.
This is actually a quite common approach in NoSQL databases, especially in projects that require massively concurrent writes. By preventing conflicting writes and using an append-only data model, the scalability improves immensely. It is also the model used behind the "op log" files of many (relational) databases. By keeping a log of all operations, they can reconstruct the database from the start.
在许多情况下，您还会偶尔存储文档状态的快照，以便更快地确定当前文档.这可以由随机客户端完成，也可以由受信任的进程完成，例如在您控制的服务器或 Cloud Functions for Firebase 上.
In many cases you'll then also store occasional snapshots of the document state, to make it faster to determine the current document. This can either be done by a random client, or by a trusted process such as on a server you control or Cloud Functions for Firebase.
这篇关于Firestore 离线设备上线时会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
