我們是否需要複雜的GCM/FCM發送策略？

Question

目前我正在開發SaaS，支持多個租戶，可以爲他們的用戶羣啓用推送通知。 我正在考慮使用消息隊列來存儲所有推送並使用單獨的服務發送它們。該新服務需要從隊列中讀取併發送推送通知。

我現在的問題是：我需要想出一個複雜的發送策略？我知道使用GCM每個請求最多有1000個設備，因此需要考慮這一點。我也不能等待x推進，因爲這可能會延遲先前發送的推送。我的下一個想法是創建一個全局數組，並通過從隊列中推入來填充它。然後循環會每隔1秒取出一個數組併發送推送。這種方式推送肯定會發送，我不會超過1000個設備的限制。

所以......雖然這可能工作，我不知道如果一個無限循環是最好的方式去。我想知道GCM/FCM是否有請求限制？如果不是的話，我不需要首先將推動力集中起來，我就可以放棄這個循環。我可以簡單地爲每個從隊列中取出的推送發出請求。

對這個話題的任何啓發或改進我的原型算法將是偉大的！

Answer 1

我需要想出一個複雜的發送策略嗎？

不是真的。 GCM/FCM非常簡單。只需將消息發送到GCM/FCM服務器，然後將它自己排隊，然後（根據行爲）儘快發送。

我知道使用GCM每個請求有1000個設備的限制，所以這需要考慮。

我覺得你對每個請求限制的1000個設備感到困惑。 1000個設備限制是指使用registration_ids參數當在列表中添加註冊的令牌的數量：接收多播消息

此參數指定的設備的列表（註冊標記，或ID）。它必須包含至少1個和最多1000個註冊令牌。

這意味着您只能在單個請求中發送1000個具有相同消息負載的設備（如果需要，您可以執行批量請求（1000 /每個請求））。

我想知道GCM/FCM是否有請求限制？

AFAIK，沒有這樣的限制。溝環。只要您成功向GCM/FCM服務器發送消息，它就會排隊並保留消息，直到消息可以發送。