Firestore 事务被多次触发导致数据错误

Question

所以我有一个云功能，每次交易被喜欢/不喜欢时都会触发。此函数增加/减少likesCount。我已经使用 firestore 事务来实现相同的目的。我认为问题是事务块内的代码被多次执行，根据文档，这可能是正确的。

但我的点赞数在某些时候更新不正确。

 return firestore.runTransaction(function (transaction) {
        return transaction.get(transRef).then(function (transDoc) {
            let currentLikesCount = transDoc.get("likesCount");
            if (event.data && !event.data.previous) {
                newLikesCount = currentLikesCount == 0 || isNaN(currentLikesCount) ? 1 : transDoc.get("likesCount") + 1;
            } else {
                newLikesCount = currentLikesCount == 0 || isNaN(currentLikesCount) ? 0 : transDoc.get("likesCount") - 1;
            }
            transaction.update(transRef, { likesCount: newLikesCount });
        });
    });

任何人都有类似的经历

Answer 1

伙计们终于找到了这种意外行为的原因。

如果您的应用程序将是流量密集型的，则 Firestore 不适合维护计数器。他们在他们的文档中提到了它。他们建议的解决方案是使用分布式计数器。

许多实时应用程序都有充当计数器的文档。例如，您可以计算帖子的“喜欢”或特定项目的“收藏”。

在 Cloud Firestore 中，您大约每秒只能更新一个文档，这对于某些高流量应用程序来说可能太低了。

https://cloud.google.com/firestore/docs/solutions/counters

我不相信这种方法，因为它对于一个简单的用例来说太复杂了，当时我偶然发现了以下博客

https://medium.com/evenbit/on-collision-course-with-cloud-firestore-7af26242bc2d

这些人使用了 Firestore + Firebase 的组合，从而消除了他们的弱点。

Cloud Firestore 位于 Firebase 实时数据库附近，非常方便，两者可以轻松地在应用程序中使用、混合和匹配。如果满足您的需要，您可以自由选择在两个位置为您的项目存储数据。

那么，为什么不使用实时数据库的优势之一：管理来自分布式客户端的快速数据流。这是尝试在 Firestore 中聚合和计算数据时出现的一个问题。

说 Firestore 是对实时数据库的升级（正如它所宣传的那样）是不正确的，而是一个具有不同目的的不同数据库，两者可以并且应该在大型应用程序中共存。这就是我的想法。