如何在客户端对Firestore的snapshots数据流实现节流管控

问题描述 #

代码异常导致短时间内向Firestore数据库写入1000次，数秒内回读约5万份文档。该问题由写入操作调用bug导致，触发Firebase的snapshots()流执行1000次，每次对应约50次读取，需从客户端侧优先解决，避免后续同类问题出现。

现有节流方案的局限 #

已调研RxDart包的流节流相关能力，相关方法签名如下：

Stream<T> throttle( Stream window( T event ), {bool trailing = false, bool leading = true} )

官方对该方法的说明如下：

发出源Stream的一个值后，在窗口Stream处于打开状态时忽略后续源值，之后重复该流程。
若leading参数为true，会发出每个窗口中的第一个项；若trailing参数为true，会发出每个窗口中的最后一个项。
你可以使用上一个被节流事件的值来决定下一个窗口的时长。

该节流功能仅会简单丢弃流输出的数据，实际读取操作已经执行，若循环写入问题未被捕获，仍可能产生极高的成本风险，无法满足需求。

客户端侧优化方案 #

可通过以下多层逻辑叠加，从根源避免异常读写产生：

• 订阅去重：为所有snapshots()流订阅生成唯一标识（可组合查询路径、查询参数、用户ID等字段），触发新订阅前校验是否存在同标识的活跃订阅，存在则直接复用现有订阅，避免重复建立监听触发重复读取。
• 写入操作防抖：对触发Firestore写入的上层业务方法添加防抖逻辑，防抖窗口可按业务场景设置为300ms~1s，短时间内重复调用的写入操作会合并为单次执行，从根源避免大量写入触发批量流更新。
• 订阅触发前置节流：将节流逻辑放到流订阅触发的前置节点，相同条件的流订阅触发请求在节流窗口内仅放行第一次，避免多余的监听被注册到Firebase SDK层，从源头阻断多余读取请求。
• 本地熔断机制：监听Firestore读写请求的频次，若10s内读写请求量超出预设阈值（可按业务常规峰值的2~3倍设置），则直接熔断对应模块的读写操作，输出异常日志告警，避免异常请求持续消耗配额。

可搭配Firestore规则的单用户/单IP请求阈值限制作为兜底方案，用于拦截极端异常场景的请求，降低成本风险。

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