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