一个受欢迎的项目将如何处理每个项目主题订阅的速率限制？
How will a popular project handle rate-limit for topic subscriptions per project?
简介
来自官方的 firebase 文档。它在那里指出：
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.
The topic subscription add/remove rate is limited to 3,000 QPS per project.
qps = 每秒查询数。
事情是这样的。它说 “每个项目”。如果一个应用程序变得非常流行并且成千上万的用户同时打开该应用程序然后单击订阅主题或取消订阅的按钮怎么办？
达到速率限制 3000 queries per second 的可能性不大吗？
这是我真正的问题
firebase_messaging 的 subscribeToTopic(..) 和 unsubscribeFromTopic(..) 方法是否自动处理重试？ （参考上文“使用指数退避重试”）
如果不是，那么一个非常受欢迎的应用程序将如何处理来自大量用户的主题订阅？
因为插件没有提供任何相关文档。
关于subscribeToTopic()重试？的问题来自不同的平台（Android），但可能 两者的功能相似。 where in Flutter it returns Future（如果我理解正确的话，Task = Future for Flutter），我认为这是一个暗示 Google 将重试的责任交给了开发人员。
我不确定您在寻找什么答案。正确的方法是实现文档中提到的指数退避。根据您的用例，可以实施不同的策略。
例如强制订阅——就像一般主题一样，运行每个应用程序启动很容易。一次性订阅，您可能需要一些验证，即一种检查用户是否真正完成订阅的方法，如果没有则重试。
简介
来自官方的 firebase 文档。它在那里指出：
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a
429 RESOURCE_EXHAUSTED("quota exceeded") response. Retry with exponential backoff.
The topic subscription add/remove rate is limited to 3,000 QPS per project.
qps = 每秒查询数。
事情是这样的。它说 “每个项目”。如果一个应用程序变得非常流行并且成千上万的用户同时打开该应用程序然后单击订阅主题或取消订阅的按钮怎么办？
达到速率限制 3000 queries per second 的可能性不大吗？
这是我真正的问题
firebase_messaging 的 subscribeToTopic(..) 和 unsubscribeFromTopic(..) 方法是否自动处理重试？ （参考上文“使用指数退避重试”）
如果不是，那么一个非常受欢迎的应用程序将如何处理来自大量用户的主题订阅？
因为插件没有提供任何相关文档。
关于subscribeToTopic()重试？的问题来自不同的平台（Android），但可能 两者的功能相似。
我不确定您在寻找什么答案。正确的方法是实现文档中提到的指数退避。根据您的用例，可以实施不同的策略。
例如强制订阅——就像一般主题一样，运行每个应用程序启动很容易。一次性订阅，您可能需要一些验证，即一种检查用户是否真正完成订阅的方法，如果没有则重试。