Firebase FCM 变得非常不稳定。寻找解决方案/替代方案

Posted 2023-02-24

【中文标题】Firebase FCM 变得非常不稳定。寻找解决方案/替代方案

【英文标题】：Firebase FCM has become very unstable. Looking for a solution / alternatives

【发布时间】：2019-03-30 18:40:21

【问题描述】：

我们拥有超过一百万订阅者的应用正面临着 FCM 的巨大交付问题。最近情况变得更糟，服务几乎不再工作了。我们收到如下错误：

  code: 'messaging/message-rate-exceeded',
 message: 'Topic quota exceeded.' ,
codePrefix: 'messaging' 

我们经常遇到这个错误。在欧盟/美国晚上，情况似乎更糟。在某些情况下，超过 90% 的通知都失败了。 我们正在与 firebase 支持团队联系，但到目前为止似乎还没有解决方案。不过，这给了我们很多信息和一些有用的事实：

资源在开发人员之间共享。因此，最大消息速率可能会因其他开发者占用资源而有所不同。 OR 查询应转换为多个 AND 查询，因为 OR 查询实际上会向所有用户群生成消息，然后应用过滤条件 240 条消息/分钟和 5,000 条消息/小时发送到单个设备。 将上游消息限制为每个项目 15,000 条/分钟（我们不理解这一点） 将每台设备的上行消息限制为 1,000 条/分钟

他们还在https://firebase.google.com/docs/cloud-messaging/concept-options#topics_throttling 更新了他们的文档

所以我们知道消息速率限制和扇出机制。在我们的例子中，我们每小时大约有 6000 个不同的主题发送请求，每个主题平均有 10k 订阅者。 单个用户每小时收到的通知永远不会超过 50-100 条。 我们相信我们没有达到 FCM 设定的限制。

回到 GCM 时代，一切正常。所以我们对目前的情况非常不满。该应用程序的核心功能现在真的很糟糕。而且似乎没有解决方案。

我们正在考虑改用 SSE 解决方案。 有一个关于某人成功离开 FCM 的故事 https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html 但由于谷歌最近让后台进程运行变得非常困难，我想知道其他有类似经历的人是怎么做的。 或者我们还能解决这个问题吗？

【问题讨论】：

由于您遇到的大多数限制似乎与主题有关，您可以考虑基于 FCM 令牌和send batches of messages using the Admin SDK 或the registration_ids parameter in the legacy API 实现自己的主题系统。

我使用旧版 v1 API 将所有主题调用转换为带有注册 ID 的“发送”调用。让我们看看它的行为。

您找到问题的解决方案了吗？

是的，我们采用了旧的发送通知方式。因此，我们为每个设备注册 gcm 令牌并发送批量通知。看起来 Google Firebase 团队根本不在乎中型公司。

【参考方案1】：

Cloud Alert 是一个这样的选择——它可以替代 FCM，提供高吞吐量和无限的消息。它使用后台作业并维护自己与专用服务器的连接。虽然存在免费计划，但您的 100 万连接要求将使您进入付费计划。

披露：我为 Cloud Alert 工作。