云修复中计数器的正确处理

Question

期望结果

我的应用程序将用户的events和responses存储在Firestore中。用户可以保存关于其出勤情况的不同类型的响应(例如“是”、“否”、“可能”、“休假时”)。

计数器跟踪不同的响应类型，并存储在事件文档中。每当添加或更新响应时，云函数(onWrite触发器)将增加或减少事件文档中的计数器。当列出所有事件时，可以立即使用来自计数器字段的数据显示响应总数。

云修复中的数据结构：

[events] / {eventDoc} / [responses] / {responseDocs}

eventDoc存储所有的事件细节(例如标题、开始、结束、位置)。

当用户回复他们的个人出勤信息(例如“是”、“否”、.)时，会在responses集合中使用他们的uid创建一个新的responses。因此，每个响应都是一个单独的文档！

问题

由于每秒写1次的限制，我担心如果大量用户同时更新响应，计数器中可能会出现延迟，尤其是错误。如果计数器没有显示正确的数据，它们就没有什么意义。

在这种情况下应该使用分布式计数器吗？

我不确定这里是否需要一个分布式计数器，因为用户响应不是存储在一个eventDoc中，而是存储在子集合中的单独文档中。

问题

我应该像上面描述的那样使用触发云函数还是应该在客户机上实现计数器的调整？

客户端的事务可以确保只有在事件文档上的相应计数器值也被更新时才会创建或更新响应。但是，如果执行失败，这只会导致用户失望。那幂等云函数呢？

对此的任何反馈都是非常感谢的！

Answer 1

由于每秒写1次的限制，我担心如果大量用户同时更新响应，计数器中可能会出现延迟，尤其是错误。

如果您要将所有响应存储在一个文档中，并且害怕每秒写入1次，那么您应该考虑创建四个不同的文档，而不是一个文档。因此，与其拥有：

[events] / {eventDoc} / [responses] / {responseDocs}

您可以在“响应”集合下添加：

[events] / {eventDoc} / [responses]

四份文件：

{yesResponse}, {noResponse}, {maybeResponse}, {onVacationResponse}

这样，您将减少每个文档的写入次数。关于账单，如果您写入单个文档或四个文档，写入的次数将是相同的。

此外，如果您检查正式文件，就会发现：

保持每秒一次以上的写入速率会增加延迟并导致争用错误。这不是一个硬极限，你可以在短时间内突破极限。

所以你应该考虑在短时间内突破极限，就像上面提到的。

如果这也不能解决您的问题，那么您应该考虑使用实时数据库，在那里您可以每个数据库写入最多1,000次/秒。

幸运的是，即使在实时数据库中，您也可以像在原子地增加计数器中一样使用云雾恢复。

编辑：

应该像上面描述的那样使用触发云功能，还是应该在客户端上实现计数器的调整？

我会继续使用云功能。在这种情况下，所有的增量逻辑都隐藏在可信的环境中，除此之外，它将更快。

但是，如果执行失败，这只会导致用户失望。

是的，这是一个糟糕的用户体验，应该尽量避免。