什么时候应该使用Firebase事务



我理解Firebase事务启用某些值的原子更新,给定其旧值和新值

但是考虑到Firebase是一个实时数据库,我认为,必须谨慎地使用事务,而不是在'实时功能'

这里有一个例子:

  1. 我明白,如果你正在对一个值执行一些数学运算(添加"喜欢"或等效),使用transaction

  2. 是有意义的。
  3. 我不明白在以下用例中使用事务是否有意义:假设一个文本字段可以由任意数量的用户更新,我们对所有更新感兴趣,因为它们是实时发生的。在这种情况下,firebase是否建议我们使用事务?或者最终的"持久化操作"发生在值上,仅限制为Firebase服务器时钟的每个时间戳粒度的单个"持久化操作"?

是否保证事件将按照保存最终值的顺序交付?

无论何时在数据库上使用事务,都要牺牲一些可伸缩性以获得更强的数据一致性保证。Firebase数据库上的事务没有什么不同,除了开发人员倾向于在更高并发性的情况下使用Firebase。

对于任何事务系统:保持系统可伸缩性的关键是尽量减少争用更新相同数据的客户端数量。在Firebase的情况下,您可以通过在JSON树中尽可能低地运行事务来实现这一点。例如,计数器是在事务下可以很好地工作的一个例子。

对于较大的数据块,例如您的文本编辑示例,使用事务将不能很好地扩展。对于这样的用例,最好找到一种完全避免冲突的方法。这通常归结为存储每个用户正在生成的增量,而不是存储更新后的状态。一个很好的例子是Firepad,它使用操作转换在Firebase数据库之上创建了一个高度并发的协作编辑器。

最新更新