分块发送GCM通知：如何将响应消息ID与请求按序对应存储

问题本质 #

GCM（Google Cloud Messaging）的批量请求返回的results数组不保证与请求中registration_ids的顺序一致，所以无法通过索引位置直接匹配。你需要通过「注册ID-自定义标识」的映射来关联每个消息ID和对应的请求目标。

具体解决步骤 #

• 1. 预存映射关系
  在发送每块500人的请求前，先把当前批次里的每个registration_id和你的业务唯一标识（比如用户ID、UUID）绑定，存入临时映射表（比如内存字典、Redis缓存或数据库临时表）。示例：

  # Python示例：构造注册ID与用户ID的映射
  batch_reg_ids = ["reg_001", "reg_002", ..., "reg_500"]
  batch_user_ids = ["user_1001", "user_1002", ..., "user_1500"]
  reg_to_user = dict(zip(batch_reg_ids, batch_user_ids))
  

• 2. 构造批量请求
  按GCM要求发送批量请求，无需额外添加自定义字段（因为返回结果不会携带这些字段），只需确保发送的registration_ids列表和你预存映射的列表完全对应：

  {
    "registration_ids": ["reg_001", "reg_002", ..., "reg_500"],
    "data": {
      "title": "通知标题",
      "body": "通知内容"
    }
  }
  

• 3. 解析返回结果并关联存储
  遍历GCM返回的results数组，对每个结果项：

  • 提取registration_id（如果返回了更新后的ID，优先用这个）和message_id（或error字段）。
  • 通过registration_id在预存的映射表中找到对应的业务标识（比如用户ID）。
  • 将业务标识、registration_id、message_id（或错误信息）、发送时间等信息存入正式存储（比如数据库的通知日志表）。
  • 如果返回了新的registration_id，记得更新你的用户注册ID存储，避免后续发送失败。

关键注意事项 #

• 永远不要依赖返回结果的顺序与请求顺序一致，GCM官方文档明确说明批量请求的结果顺序是不确定的。
• 映射表的生命周期只需覆盖当前批次的处理即可，处理完后可以清理，避免占用资源。
• 对于失败的请求（比如error: "InvalidRegistration"），也要关联对应的业务标识，方便后续重试或记录问题。

内容的提问来源于stack exchange，提问作者Manish Mishra