Firestore原子increment更新的原子性强度及高并发场景限制问题

原子性本身的可靠性 #

increment(number) 操作的原子性逻辑是完全可靠的：该操作直接在Firestore服务端存储层执行，不需要客户端预先读取文档内容，也不会受并发写冲突的影响。只要你的请求没有被系统拒绝、成功执行完成，累加结果一定是正确的，不会出现写覆盖、漏加、多加的问题，这一点没有逻辑上的缺陷。

极端场景下的实际限制 #

你假设的「1秒内1万次同文档increment请求」场景里，increment的原子性本身不会出问题，但会触发Firestore的其他硬限制，导致绝大多数请求无法正常执行：

• 首先会触及单文档写入吞吐量上限：Firestore官方明确要求单个文档的持续写入频率不能超过1次/秒，最多可承受数十次/秒的突发写入，远低于你假设的1万次/秒的量级。超过这个阈值的请求会直接返回RESOURCE_EXHAUSTED限流错误，根本不会进入到原子修改的执行环节，自然也不会完成累加。
• 你提到的每秒1万次写入是整个Firestore实例的全局限制，在这个场景里还没有触碰到，单文档的限制就已经先拦截了绝大多数请求。

此外还有一个和原子性无关的精度问题：如果你累加的是0-1之间的双精度浮点数，当累加次数足够多时，可能会出现浮点数精度丢失导致的微小误差，这是浮点数本身的特性导致的，如果需要完全精确的小数计算，建议先将数值放大为整数单位（比如将元转换为分存储）后再执行increment操作。

高并发计数场景的落地建议 #

类似点赞数、播放量这种需要扛高并发更新的计数场景，不要直接用单文档存储+increment的方案，官方推荐的优化方案是分布式计数器：将计数字段拆分到多个分片文档中，每次更新随机选择一个分片执行increment，查询时汇总所有分片的数值求和，以此避开单文档的写入吞吐量限制，可支撑每秒数万级的并发更新需求。

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