失败之前，Firebase事务的最大重试次数是多少 [英] What is the maximum number of retries for Firebase transaction before failing

问题描述

我在Firebase下有一个针对不同餐厅的节点，其中包含活动和过去的访问者列表.该节点名为 listvisitors .在餐厅节点下，我想为所有访客提供一个柜台.这是我要使用Firebase交易的地方.

I have a node under Firebase for different restaurants which contains a list of active and past visitors. This node is named listvisitors. Under the restaurant node, i want a counter for all the visitors. Here is where I want to use Firebase transactions.

这个想法是当一个人打开餐厅页面时增加计数器.可能会有争执，交易似乎是一个不错的选择.

The idea is to increment the counter when a person opens the restaurant page. As there would be contention, transaction seems like a good option.

一家受欢迎的餐厅可能会同时吸引大量访客，从而引起竞争.交易可以扩展以解决此问题吗?

A popular restaurant can have loads of visitors simultaneously visiting thus leading to contention. Can transactions scale to handle this?

如果是这样，在发生最大重试错误失败之前，事务可以处理的最大重试次数是多少.(基本上是假设所有用户都同时登录的最大同时更新次数)

If so, what is the maximum retries that transaction can handle before failing with the max retries error. (Essentially the max simultaneous updates assuming all users log in at the same time)

如果没有.是否有一种有效的替代方法，可以从本质上计算列表下的当前子代数并获取正确的子代数?

If not. Is there an efficient alternative to essentially count the number of current children under lists and get the correct number?

推荐答案

如果Firebase客户端在25次尝试后仍未成功，则当前将中止该事务.

The Firebase client currently aborts the transaction if it hasn't succeeded after 25 tries.

在您看到争用程度之前，明智的做法是更改为其他策略.解决此问题的常用方法是，不让每个访问者更新公共计数器，而是让每个访问者使用 push():

Well before you see that level of contention it'd be wise to change to a different strategy. The common way to solve this problem is to not have each visitor update the common counter, but instead have each of them write a "I visited this" into the database with a push():

ref.child("visits").push().setValue(currentUser.getUid());

然后，您可以有一个服务器端进程，该进程将访问从列表中拉出并增加计数器.在稳定状态下，这意味着 visits 的列表为空.任何时候 visits 列表仅包含尚未计算的访问.

Then you can have a server-side process that pulls the visits off the list and that increments the counter. In a stable state that means that the list of visits is empty. At any moment the visits list only contains visits that haven't been counted yet.

之所以会执行得更好，是因为服务器端进程不会有任何争用更新计数器.因此，它实际上并不需要使用事务.但是，即使它确实使用了事务，也将永远"不必重试.

The reason this will perform better is that the server-side process will not have any contention for updating the counter. So it doesn't really need to use a transaction. But even if it does use a transaction, it will "never" have to retry.

这篇关于失败之前，Firebase事务的最大重试次数是多少的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！