我了解 Firebase 事务允许对某些值进行原子更新，考虑到其旧值和新值
但考虑到 Firebase 是一个实时数据库，我认为，必须谨慎使用事务，而不是在“实时功能”中使用事务
这是一个例子：
我了解，如果您对某个值执行一些数学运算（添加“喜欢”或等效项），则使用事务是有意义的
我不明白在以下用例中使用事务是否有意义：假设一个文本字段可以由任意数量的用户更新，我们对所有更新感兴趣，因为它们是实时发生的. firebase 是否建议我们在这种情况下使用事务？还是在值上发生的最终“持久操作”仅限于 Firebase 服务器时钟的每个时间戳粒度的单个“持久操作”？
是否进一步保证事件将按照最终值被持久化的顺序传递？
【问题讨论】：
标签： firebase firebase-realtime-database
每当您在数据库上使用事务时，您都会牺牲一些可伸缩性以获得更强大的数据一致性保证。 Firebase 数据库上的事务没有什么不同，只是开发人员可能倾向于在更高并发的情况下使用 Firebase。
对于任何事务系统：保持系统可扩展性的关键是尽量减少争用更新相同数据的客户端数量。对于 Firebase，您可以通过在 JSON 树中尽可能低地运行事务来实现这一点。 IE。计数器是可以在事务下正常工作的示例。
对于较大的数据，例如您的文本编辑示例，使用事务将无法很好地扩展。对于这样的用例，最好找到一种完全避免冲突的方法。这通常归结为存储每个用户正在制作的增量，而不是存储更新的状态。 Firepad example 就是一个很好的例子，它使用操作转换在 Firebase 数据库之上创建一个高度并发的协作编辑器。
【讨论】：
latestCommentId 值的争用，您可能会过早地进行优化。可以通过将时间戳包含为latestCommentId 的值来防止用较旧的日期覆盖，然后拒绝时间戳比当前存在的时间戳要旧。但请注意，我们在这里从一个非常广泛的问题变成了一个非常详细的用例。您可能想先花更多时间处理 Firebase 事务，然后再提出更具体的代码和安全规则问题。