Firebase Firestore计数测试疑问及Distributed Counter扩展作用咨询

问题1：你提供的安全规则是否存在错误 #

从本次测试所有自增操作全部成功、最终计数完全符合预期的结果来看，你使用的安全规则不存在语法或逻辑错误，可以正常支持当前场景下的Likes字段更新操作。

问题2：Distributed Counter扩展的优势及使用必要性 #

你当前的测试属于低并发、短时间的突发写入场景，Firestore本身对短时间突发写入有一定容忍度，所以单字段原子自增可以正常运行，但放到生产环境这种方案有明显局限，分布式计数器扩展的核心价值如下：

• 突破单文档写入上限：Firestore官方推荐单文档持续写入不要超过每秒1次，你现在测试的总写入QPS只有16，属于短时间突发流量可以被临时支撑，但如果生产环境遇到热门内容上万用户同时点赞的场景，单文档会出现大量写入超时、失败的问题。分布式计数器将计数拆分到多个独立分片文档，写入压力分摊到不同分片，最高可支持每秒上万次的计数写入，完全覆盖高并发场景需求。
• 规避高并发冲突：虽然本次测试用FieldValue.increment原子操作没有出现计数错误，但如果并发量进一步升高，或者业务逻辑涉及先读再写的计数更新场景，很容易出现并发覆盖导致计数不准的问题，分布式计数器的分片写入机制从底层规避了这类并发冲突。
• 降低开发成本：官方分布式计数器扩展已经封装好了分片创建、写入路由、计数聚合的全部逻辑，不需要手动实现分片计数的复杂逻辑，直接调用封装好的方法读写即可，减少自研方案的出错概率。
• 提升服务稳定性：生产环境流量不可控，活动推广、内容爆火都可能带来短时间的计数请求暴涨，分布式计数器是经过官方验证的高可用方案，可以保证计数服务的稳定性，避免高并发下计数服务不可用的问题。

内容的提问来源于stack exchange，提问作者Taha Sami