所需结果
我的应用程序将我的用户的events和responses存储在Firebase Cloud Firestore中。用户可以保存关于其出席情况的不同类型的响应(例如"是"、"否"、"可能"、"休假"(。
计数器跟踪不同的响应类型，并存储在事件文档中。每当添加或更新响应时，Cloud Function(onWrite触发器(都会增加或减少事件文档中的计数器。列出所有事件后，可以使用计数器字段中的数据立即显示响应总数。
Cloud Firestore中的数据结构：
[events] / {eventDoc} / [responses] / {responseDocs}
eventDoc存储所有事件细节(例如标题、开始、结束、位置(。
当用户用他们的个人考勤详细信息回复(例如"是"、"否"、…(时，在responses集合中用他们的uid创建新的responseDoc。因此，每个回复都是一个单独的文档！
问题
由于每秒写入1次的限制，我担心如果大量用户同时更新响应，可能会出现延迟，尤其是计数器中的错误。如果计数器没有显示正确的数据，那么它们就没有什么意义。
在这种情况下应该使用分布式计数器吗
我不确定这里是否需要分布式计数器，因为用户响应不是存储在一个eventDoc中，而是存储在子集合中的单独文档中。
问题
我应该使用如上所述的触发云功能，还是应该在客户端上实现计数器的调整
客户端的事务可以确保只有在事件文档上的相应计数器值也更新的情况下才会创建或更新响应。然而，如果执行失败，这可能会导致用户感到沮丧。那么幂等云函数呢？
非常感谢对此的任何反馈
由于每秒写入1次的限制，我担心如果大量用户同时更新响应，可能会出现延迟，尤其是计数器中的错误。
如果您将所有响应存储到一个文档中，并且担心每秒写入1次的限制，那么您应该考虑创建四个不同的文档，而不是一个。因此，与其拥有：
[events] / {eventDoc} / [responses] / {responseDocs}
您可以在"；响应"；集合：
[events] / {eventDoc} / [responses]
四份文件：
{yesResponse}, {noResponse}, {maybeResponse}, {onVacationResponse}
通过这种方式，您将减少每个文档的写入次数。关于计费，无论您是在一个文档中还是在四个文档中写入，写入次数都是相同的。
除此之外，如果你查看官方文件，据说：
将写入速率保持在每秒一次以上会增加延迟并导致争用错误。这不是一个硬性限制，你可以在短时间内超越这个限制。
因此，您应该考虑在短时间内超过极限，如前所述。
如果这也不能解决您的问题，那么您应该考虑使用实时数据库，在该数据库中，每个数据库每秒最多可以写入1000次写入。
幸运的是，即使在实时数据库中，也可以像在Cloud Firestore中那样使用原子递增计数器。
编辑：
我应该使用如上所述的触发云功能，还是应该在客户端上实现计数器的调整？
我会继续使用云功能。在这种情况下，所有的递增逻辑都隐藏在一个可信的环境中，除此之外，它会更快。
然而，如果执行失败，这可能会导致用户感到沮丧。
是的，这是一种糟糕的用户体验，应该尽可能避免。