【发布时间】:2022-02-09 23:40:17
【问题描述】:
我正在运行一个具有 160k DAU 的 Firebase 应用,这是一款在线回合制游戏,它使用 RTDB 在玩家之间发送更新。在最繁忙的时间,我的数据库负载峰值约为 60%。
对我来说很长一段时间的问题是如何在比赛结束后“清理”比赛节点。当前结构:
root/games/$gameId
gameId 由主机在匹配过程中提供。之后,两个玩家都订阅这个节点并发送更新。
我可以做的是让 2 个客户端中的一个在游戏结束后删除节点,但这将是另一个(不可靠的)写入以增加数据库负载。我的主要目标是将“死游戏节点”保持在最低限度,从而降低存储成本(Blaze 计划)。我最近才知道这个扩展,但我很好奇我的“成本”是多少。
Q1:这个扩展的每个触发器都会算作对我的数据库的“写入”吗?鉴于一个实例每秒只允许 1000 次写入,这将进一步增加此计数(每秒会触发多次)。
Q2:在 youtube 信息视频中,它说使用自动生成的 ID“效果最好”,但它需要吗? https://www.youtube.com/watch?v=i_u_6RknUro
我知道这个扩展实际上只是一个云功能,但在我敢于使用它之前,我想知道它在幕后是如何工作的:)
感谢您的帮助:)
【问题讨论】:
标签: firebase firebase-realtime-database