database - Firebase Firestore的幂等计数器实现

Question

从文档中:

This may also result in multple invocations for a single event, so for the highest quality functions ensure that the functions are written to be idempotent.

因此，如果Firestore无法提供一种方法来计算集合中子文档的数量，那么我需要创建一个云函数来将该信息聚合到一个节点上，例如 /counters/{type}/count。

如果我执行写触发器并增加该值，那么我的计数器可能不会反射(reflect)实际的文档计数，对吗？

如何编写一个函数以完美地计算集合中的文档数量(而又不会太昂贵-假设我不想在每次写入时都读取整个集合)？

Answer 1

这个问题的答案将取决于您如何使用集合的不同方面，以及“完全计数”对您而言意味着什么。
前言
首先，由于Cloud Function调用与写入异步，因此将导致计数器稍微落后于集合的真实计数。我认为这还可以。
即使您通过阅读每个文档来对集合进行计数，但由于计数时可能已插入或删除了文档，因此计数仍然过时。
费用表
您提到“不要太贵”。在这里，我们需要了解读取计数的频率与添加或删除文档的频率。为了维护一个单独的计数器，您将在每次文档计数更改时对其进行读取/写入。由于写入的价格是读取价格的3倍，因此这意味着您需要对每个文档进行4次或更多次计数才能收回保持计数的成本。这里某处存在一个公式，该公式考虑了文档生命周期内的平均计数，但是我将其留给读者练习。
幂等计数器
这是一个有趣的问题，这是分布式系统中另一个熟悉的问题。如果客户端请求添加+1计数器，并且请求超时(服务器永不响应)，再次请求是否安全？如果服务器确实应用了增量但又遇到网络问题怎么办？如果没有呢？
下面，我将回答一些解决这种情况的方法。
幂等计数器-交易ID
一种解决方法是发送带有增量请求的唯一事务ID(txid)。如果服务器之前已经处理过txid，则它知道它是重复请求，并且可以响应它已经完成了该请求。
在您的用例中，如果您从不删除文档，则可以将文档ID用作txid。 +1时，在计数器中，将文档ID添加到经过处理的增量数组中。在执行此操作之前，请检查它在数组中是否不存在(表明它已被处理)。
上面的一个明显问题是阵列将继续增长，最终变得太大。因此，我们将希望限制跟踪旧ID的时间。您可以使用时间戳记并删除所有早于'X'的内容，也可以将数组视为循环缓冲区以将其固定为最大大小。
这两种方法对于较低的写入速度都是合理的，但对于更快的写入速度是不够的。例如，以每秒1000次写入的速度，这将是5000个文档ID，仅覆盖5秒钟(我们在我们的限制文档中提到，函数可能需要5秒钟以上的时间才能执行)。
输入健忘的布隆过滤器
幂等计数器-健忘的布隆过滤器
此方法为您提供了更高的写入速率支持，以换取您以为您以前看过文档ID的可能性很小。
我不会在此处详细介绍其实现，但是此博客对此有一个很好的概述:Counters, Idempotence And Forgetful Bloom Filters
幂等计数器-删除
另一个复杂性是处理删除。如果您使用唯一的ID，并且确定不会重复使用(例如，我们的 native Auto ID支持)，则添加起来并不难。只需在单独的列表/字段中重复添加操作即可，并确保同时检查两个列表。
要考虑的一件小事是Cloud Functions不能保证执行顺序。这意味着如果插入发生得足够近，您可能会在插入之前看到一个删除。
我的建议是，如果您在插入之前看到一个删除，请提前递减计数器，因为它知道很快就会被处理，并且如果您在删除之后看到一个插入，请执行递增操作。这是因为您只保留了这么多的历史记录，所以您无法分辨出插入和删除是否乱序，或者删除是否在插入之后太远。
其他方法
根据集合的大小，需要的准确性以及使用计数的频率，您可以定期调用Cloud Function来计算计数并将其存储在文档中。您可以根据集合的大小动态缩放此比例，以最大程度地减少延迟。对于非常小的收藏集，经常这样做，对于较大的收藏集，则很少这样做。
如果您具有确定已经计算过的文档的机制，那么您也可以在此处应用成本优化(因此您只需要计算新的)。如果很少删除，则可以添加一个事件以减少删除计数器。