【发布时间】：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_idsparameter in the legacy API 实现自己的主题系统。 -
我使用旧版 v1 API 将所有主题调用转换为带有注册 ID 的“发送”调用。让我们看看它的行为。
-
您找到问题的解决方案了吗？
-
是的，我们采用了旧的发送通知方式。因此，我们为每个设备注册 gcm 令牌并发送批量通知。看起来 Google Firebase 团队根本不在乎中型公司。
标签： android push-notification firebase-cloud-messaging