Google Play一次性产品Pub/Sub通知接收异常求助

针对你遇到的OneTimeProductNotification接收不全、StreamingPull报错问题，结合你的配置和代码，给出以下排查与修复建议：

1. 优化Pub/Sub订阅的客户端配置 #

你的Demo使用默认接收设置，可能无法应对高并发购买通知，导致消息积压或连接中断：

• 调整并发处理上限：修改订阅的ReceiveSettings，提升同时处理的消息数量：

  sub := client.Subscription("test-sub")
  // 根据业务量调整，比如设置为1000条消息或100MB的并发上限
  sub.ReceiveSettings.MaxOutstandingMessages = 1000
  sub.ReceiveSettings.MaxOutstandingBytes = 100 * 1024 * 1024
  

• 添加重连机制：Receive方法报错后直接退出会中断接收，增加循环重连逻辑：

  import "time"
  import "errors"
  
  // ... 其他代码 ...
  
  for {
      err := sub.Receive(ctx, handler)
      if err != nil {
          if errors.Is(err, context.Canceled) {
              break
          }
          log.Printf("StreamingPull错误: %v，5秒后重试", err)
          time.Sleep(5 * time.Second)
          continue
      }
      break
  }
  

• 简化handler逻辑：当前handler打印完整消息结构体可能导致IO阻塞，延迟Ack操作，建议只记录关键信息：

  handler := func(ctx context.Context, m *pubsub.Message) {
      log.Printf("收到消息ID: %s，订单数据: %s", m.ID, string(m.Data))
      m.Ack()
  }
  

2. 检查Pub/Sub订阅的消息生命周期配置 #

• 确认消息保留时长：在Cloud Console的Pub/Sub订阅详情中，检查消息保留时长是否足够（默认7天），若购买通知产生后未及时拉取，超过保留期会被删除，必要时可延长至30天。
• 配置死信队列：若存在无法正常处理的消息，会导致重复入队阻塞正常消息，开启死信队列将异常消息转移，避免影响整体接收：
  在订阅配置中设置“死信主题”，并配置最大重试次数（比如5次），超过次数的消息会被转发到死信主题，方便后续排查。

3. 验证Play Console的通知配置 #

• 确认一次性商品通知事件已全部开启：进入Play Console的应用 > 变现 > 订阅与一次性商品 > 通知页面，检查OneTimeProduct的所有事件（如PURCHASED、CANCELLED）是否都已勾选，并关联到正确的Pub/Sub主题。
• 核对主题一致性：确保Play Console中配置的通知主题，与代码中订阅的主题完全一致（包括项目ID和主题名称），避免消息发送到错误主题。

4. 排查权限与认证问题 #

• 确认服务账号权限：检查cred.json对应的服务账号，除了Topic的管理员权限，还需拥有pubsub.subscriptions.consume权限（订阅的消费权限），可在Cloud Console的IAM页面中添加该权限。
• 验证凭证有效性：确保cred.json未过期，且所属项目与绑定Play Console的项目一致，可通过以下命令验证：

  gcloud auth activate-service-account --key-file=./cred.json
  gcloud pubsub subscriptions list --project=你的项目ID
  

  若能正常列出订阅，说明凭证有效。

5. 利用Pub/Sub监控定位问题 #

在Cloud Console的Pub/Sub监控面板，查看以下关键指标：

• num_undelivered_messages：未投递消息数，若持续增长说明消息积压，需优化客户端处理能力。
• message_published_count vs message_acknowledged_count：对比主题收到的消息数和订阅确认的消息数，确认Play Console是否发送了所有购买通知。
• pull_requests_count：拉取请求失败次数，若失败率高，说明客户端连接或认证存在问题。

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