Firestore与RTDB事务推送机制咨询：批量更新是否同步到达？

嘿，针对你的两个问题，我来详细拆解Firestore和实时数据库（RTDB）的表现：

问题1：事务的执行结果是否会以单个数据块的形式推送给客户端？ #

这个得分两种数据库来看：

• Firestore：事务是原子执行的（要么全成功，要么全失败）。如果事务只更新了一个文档，客户端会收到这个文档的单个更新数据块；如果事务更新了多个文档，客户端会收到每个文档的单独更新事件，但所有这些事件都是在事务提交完成后才会触发——也就是说，你永远不会看到事务执行到一半的中间状态，所有变更都是原子性地呈现给客户端的。
• RTDB：同样遵循原子性原则。如果事务内的更新都集中在同一个父节点下，这些变更会被打包成单个数据块推送给客户端；如果更新分散在不同的节点路径下，会分成多个数据块推送，但客户端依然不会看到任何中间状态，所有变更会同时生效。

问题2：100条文档更新的事务，监听者会收到同步推送还是分批流式推送？ #

还是分数据库说明：

Firestore的表现 #

Firestore的实时更新是基于单个文档粒度的。如果你的事务更新了100个独立的文档，监听这些文档的用户B会陆续收到100个单独的更新事件——这些事件不会在事务执行过程中推送，只会在事务完全提交后才开始发送，但由于网络传输的差异，可能会在数秒内分批到达客户端。

不过要注意：虽然是分批到达，但每个文档的状态都是事务完成后的最终状态，不会出现部分更新生效的情况。如果想要实现“同步到达”的效果，你可以把这100条数据合并到同一个文档的数组/子对象中（注意Firestore单文档大小限制为1MB），这样事务更新这个单文档时，客户端只会收到一个更新事件，就能让所有变更同步呈现。

RTDB的表现 #

RTDB的推送行为取决于更新的节点结构：

• 如果100条更新都属于同一个父节点的子节点，那么这些变更会被打包成单一的原子更新推送给监听者，用户B会一次性收到所有100条更新的最终状态。
• 如果更新分散在不同的节点路径下，会分成多个数据块推送，但同样不会出现中间状态，所有变更会在事务提交后一次性生效（只是推送的数据包是分开的）。

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