Firestore 规则、原子写入和写入限制答案

【问题标题】：Firestore rules, atomic writes, and write limitsFirestore 规则、原子写入和写入限制
【发布时间】：2019-12-23 19:58:06
【问题描述】：

我有一个关于 Firestore 规则评估的两部分问题。这些部分是相关的，这就是为什么这里只有一个问题......

第一部分 - 原子写访问

假设我有一个书面规则，例如

allow write: if resource.data.claimedBy == null && request.data.claimedBy == request.auth.uid;

这个想法是任何用户都可以对该资源提出声明。但是，如果这个资源同时提供给 1000 个用户，并且他们都跳起来提出声明并同时拨打.update() 电话，该怎么办？

这会是第一次获胜的场景吗？ Firebase 将被设置为第一个用户（获胜者）的字段，然后其他所有人的写入都将被拒绝，因为规则会由于获胜者的写入中存在的值而失败？或者是否存在任何可能导致竞争条件的风险，并且不知何故，值是一回事，然后变成另一回事？

我觉得规则会禁止比赛条件，但我不确定。

第二部分 - 写入限制

好的，所以这部分建立在第一部分的基础上。 Firestore 对单个文档的写入限制通常为 1 次写入/秒。让我们假设第 I 部分按我希望的方式工作，而其他 999 名用户将收到写拒绝。这些拒绝是否因为已启动写入而计入 1 写入/秒的写入限制，还是因为规则禁止实际写入而不计入？

显然，将所有这些声明尝试同时计为 1000 次写入对于 1 次写入/秒的限制是不利的。

我在这里假设，但我相信它不会计入该限制，因为我的理解是该限制是由底层存储机制的性质强加的，并且规则阻止在拒绝时进入该层。但同样，我不确定。

第三部分 - 奖励部分

就计费而言，被规则拒绝的写入是否仍算作“写入”？我知道对不存在的文档的查询（没有实际读取的文档）仍然算作一次读取，所以我想知道关于禁止底层写入的规则的写入是否以类似的方式工作并产生费用。

非常感谢！

【问题讨论】：

【解决方案1】：

您应该使用transaction 来避免和防止并发写入。事务可以检查该文档是否先前已被声明，如果是则中止。

如果写入被规则拒绝，则不计入任何写入限制或计费，因为文档中的数据实际上没有更改。

【讨论】：

谢谢！你对你的第二个陈述有多确定？至于您的第一个陈述，我确实同意为我自己编写的客户端代码使用事务，但是当考虑到可以在我自己的客户端代码之外进行调用时，可能不会使用事务，我希望确定事务在我的示例中给出的规则的情况下，基本上是“无用的”/不必要的。
您必须确保所有客户端都使用事务。如果你不这样做，你就不能确保写入是原子的，并且一个写入可能会破坏另一个。我对第二部分很确定。
再次感谢您。对我来说，事务对于应该/可以考虑所有写入的并发写入很有用。如果我没有那个规则，我 100% 同意非事务写入会互相破坏。但是，我正在尝试确定我编写的规则是否实际上会阻止所有后续/并发写入，并以原子方式进行。如何/何时评估规则的机制是关键部分。
如果你是正确的，我必须确保交易，当考虑到恶意客户时，我认为我唯一的选择是通过使用交易的 firebase 功能进行“索赔”并限制直接对客户端的写访问。这不会那么糟糕，但它会强制每个请求对事务逻辑进行一次读取，并且会施加稍长的延迟调用函数。
当然，如果你想让每个人都通过一个端点。这是有效的。