使用最新HTTP API向多设备发送FCM通知的替代方案咨询

1. 优先使用FCM HTTP v1 API的批量请求（Batch Requests） #

这是替代Legacy API中registration_ids批量发送的最优方案，核心是将多个单令牌的发送请求打包成一个HTTP请求提交给FCM：

• 采用multipart/mixed请求格式，每个子请求对应一个目标设备令牌的消息发送逻辑，子请求结构和单独发送时完全一致。
• 优势：大幅减少TCP连接开销，相比逐个发送能显著提升整体发送效率，且FCM会按子请求的实际消息数统计，而非外层请求数计算限流。
• 简化示例结构：

  POST /batch HTTP/1.1
  Host: fcm.googleapis.com
  Authorization: Bearer <ACCESS_TOKEN>
  Content-Type: multipart/mixed; boundary=batch_boundary
  
  --batch_boundary
  Content-Type: application/http
  Content-Transfer-Encoding: binary
  
  POST /v1/projects/<PROJECT_ID>/messages:send HTTP/1.1
  Content-Type: application/json
  
  {"message":{"token":"TOKEN_1","notification":{"title":"Test"}}}
  
  --batch_boundary
  Content-Type: application/http
  Content-Transfer-Encoding: binary
  
  POST /v1/projects/<PROJECT_ID>/messages:send HTTP/1.1
  Content-Type: application/json
  
  {"message":{"token":"TOKEN_2","notification":{"title":"Test"}}}
  
  --batch_boundary--
  

2. Device Group的限制说明 #

Device Group确实最多仅支持20个注册令牌，若你需要推送的设备数超过该数量，此方案无法满足需求，建议直接采用批量请求方案。

3. FCM的限流机制说明 #

FCM的限流基于每秒发送的消息总数，而非请求次数，具体限额根据项目类型（免费/付费）有所区别：

• 免费项目有基础发送限额，付费项目可获得更高的配额。
• 触发限流时，FCM会返回429 Too Many Requests状态码，此时需实现指数退避的重试逻辑，避免持续触发限流。
• 无论是逐个发送还是批量请求，只要控制每秒发送的消息总数在限额内，就不会触发限流。

4. 当前逐个发送方案的优化建议 #

若暂时无法切换到批量请求，可通过以下方式优化：

• 控制并发请求数，使用异步请求池（如线程池、协程池）避免瞬间发送大量请求。
• 及时清理无效令牌：当FCM返回InvalidRegistration或NotRegistered时，从令牌列表中移除该条目，减少无效请求。

内容的提问来源于stack exchange，提问作者Dipu Ahmed