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创建了一个值为A的字段id，而我的设备B也创建了一个值为B的字段id.
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数据库中非常普遍的方法，尤其是在需要大量并发写入的项目中.通过防止冲突的写入并使用仅追加的数据模型，可伸缩性得到了极大的提高.它也是许多(关系)数据库的"op log"文件背后使用的模型.通过保留所有操作的日志，他们可以从头开始重建数据库.
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屋！
