使用FCM向所有已订阅主题的设备发送推送通知(批量)时出现缩放问题
我已将所有设备订阅了一个主题，即大约100万用户.在设备中收到通知后，会有一个操作按钮调用REST api.
I have subscribed all the devices to a topic i.e around 1 million users. When notification is received in the device there is an action button which calls a REST api.
现在，如果我向订阅该特定主题的所有设备触发通知，则所有用户都会收到该通知，然后点击操作按钮，该按钮将调用其余的API来获取数据.
Now if I trigger a notification to all the devices subscribed to the particular topic, all the users receive the notification and tap on the action button, which calls the rest API to fetch data.
过多的剩余API调用将CPU利用率提高到100％，并且我的服务器停止响应.
有什么方法可以使FCM向批处理中订阅该主题的所有设备发送通知，以便我的服务器可以处理负载
Is there any way I can made FCM to send notification to all the devices subscribed to a topic in the batches so that my server can handle the load
如果无法批量发送主题通知，则以下解决方法是解决方法.
Following solutions are workaround if there is no way to send the topic notification in the batch.
1.延迟在应用程序一侧显示通知的时间.
在应用程序上收到通知后，您可以决定何时向用户显示通知.以这样的方式编写逻辑，例如，某些用户将在收到通知后立即看到通知，有些用户将在2分钟后看到通知，有些用户将在4分钟后看到通知，依此类推.
After the notification received on the app, You can decide when to show it to user. Write a logic in such way that, say some user will see the notification immediately as it received, some will see it after 2 minutes, some will see it after 4 minutes and so on.
您可以使用 AlarmManager ，
You can use AlarmManager, Handler or something similar.
2.创建主题桶
假设您的主题为sport_news.将主要主题sport_news分为sport_news_1，sport_news_2，sport_news_3等.实施自己的逻辑来划分用户.
Suppose you have a topic as sport_news. Divide the main topic sport_news into sport_news_1, sport_news_2, sport_news_3 and so on. Implement your own logic to divide the users.
例如
用户将属于sport_news_1
用户将属于sport_news_2
以此类推.
因此，每当您必须将通知发送到主题sport_news时，您都将向所有属于该主题的主题发送通知，在我们的情况下将是sport_news_1，sport_news_2，依此类推.您可以按一定的时间间隔发送它以处理批处理，因为您具有服务器端控件来按批发送它.
So whenever you have to send notification to topic sport_news then you will send the notification to all the topics belong to it, in our case it will be sport_news_1, sport_news_2 and so on. You can send it on certain interval to handle the batches since you have the server side control to send it in the batches.
3.将服务器扩展一定的间隔以处理大量流量.
在将通知发送给数百万用户并知道您将获得高流量后，将服务器扩展一定的时间以处理大量流量(例如1-2小时).
After sending the notification to some million users and knowing you will get the high traffic then scale your server for certain time to handle the large traffic(say 1-2 hours).
4.改善获取数据API的延迟时间
知道特定的提取数据api会收到太多请求，因此可以在内存数据存储中实现缓存，数据库索引或其他任何方式来加快提取操作.您只需要找到一种以某种方式减少fetch api响应时间的方法，您的服务器将以此方式处理大量流量，并且CPU利用率可能会降低.
Knowing that you will get too many request for the particular fetch data api, You can implement caching, database indexing, in memory data store or any other way to speed up the fetch operation. You just have to find a way to reduce the response time for the fetch api in some way and your server will serve much traffic this way and cpu utilisation might reduced.