algorithm - 我们是否需要针对 GCM/FCM 的复杂发送策略？

Question

目前我正在开发一个支持多个租户的 SaaS，可以为他们的用户群启用推送通知。我正在考虑使用消息队列来存储所有推送并使用单独的服务发送它们。该新服务需要从队列中读取并发送推送通知。

我现在的问题是:我需要想出一个复杂的发送策略吗？我知道 GCM 对每个请求有 1000 个设备的限制，因此需要考虑这一点。我也等不及 x 推送飞进来了，因为这可能会延迟发送之前的推送。我的下一个想法是创建一个全局数组并用队列中的推送填充它。然后循环将每隔 1 秒获取该数组并发送推送。这样肯定会发送推送，而且我不会超过 1000 台设备的限制。

所以...虽然这可能有效，但我不确定无限循环是否是最好的方法。我想知道 GCM/FCM 是否有请求限制？如果没有，我就不需要首先聚合推送，我可以放弃循环。我可以简单地为从队列中拉出的每个推送发出一个请求。

任何关于这个主题的启发或对我的原型(prototype)算法的改进都会很棒!

Answer 1

Do I need to come up with a complex sending strategy?

不是真的。 GCM/FCM 非常简单。只需将消息发送到 GCM/FCM 服务器，它会自行排队，然后(根据其行为)尽快发送。

I know that with GCM has a limit of 1000 devices per request, so this needs to be considered.

我认为您混淆了每个请求 1000 台设备的限制。 1000 台设备限制是指您在使用 registration_ids 时添加到列表中的注册 token 数量。参数:

This parameter specifies a list of devices (registration tokens, or IDs) receiving a multicast message. It must contain at least 1 and at most 1000 registration tokens.

这意味着您只能在单个请求中向 1000 台设备发送具有相同消息负载的设备(如果需要，您可以随后执行批量请求(1000 个/每个请求))。

I'm wondering if GCM / FCM even has a request limit?

据我所知，没有这样的限制。摆脱循环。每当您成功向 GCM/FCM 服务器发送消息时，它将排队并保留消息，直到可以发送为止。