PubSub BigQuery订阅消息丢失求助：部分消息未写入也未进死信队列

你遇到的核心矛盾是：辅助订阅能完整接收所有消息，但BigQuery订阅存在消息“消失”的情况，既没落地BQ也没进死信。结合GCP PubSub+BigQuery集成的特性，这几个方向可以重点排查：

1. 异步写入的延迟与最终一致性问题 #

PubSub到BigQuery的订阅是异步批量写入，默认会攒够一定数量/大小的消息（或等待10秒窗口）才会发起BQ写入请求。如果测试后立刻查询BQ表，大概率有部分消息还在PubSub的缓冲队列里，尚未完成写入。另外BQ流式插入本身也有1-5分钟的延迟，批量场景下可能更久。

排查方式：发送完消息后等待20-30分钟，再对比BQ表总行数和辅助订阅的累计消息数（辅助订阅未消费，其num_messages指标就是总发送量）。同时查看订阅的num_undelivered_messages指标，直到该数值降到0后再核对数据。

2. Schema兼容性的隐性冲突 #

虽然你说主题和死信主题Schema一致，但要注意BQ表的Schema约束和主题Schema的匹配度：

• 比如主题Schema里某个字段是NULLABLE，但BQ表对应的字段设为REQUIRED，如果消息里该字段为空，会触发写入失败；
• 嵌套字段的结构、字段顺序差异（比如主题Schema是struct<id:int,name:string>，BQ表是struct<name:string,id:int>），部分场景下会导致写入失败；
• 字段类型细微不匹配，比如主题是INT64，BQ表是FLOAT64，或者主题是STRING，BQ表是DATE（且消息格式不符合日期规范）。

这类失败会触发PubSub重试，只有当重试次数达到订阅配置的max_delivery_attempts后，才会进入死信队列。如果你的max_delivery_attempts设得很高（比如10次），消息可能还在重试周期里，没到死信触发条件。

排查方式：

• 在Cloud Logging里搜索订阅名，过滤bigquery_write_errors相关日志，查看具体的失败原因；
• 把主题Schema导出，和BQ表Schema逐字段对比，确保类型、nullable、嵌套结构完全一致。

3. 死信队列的配置与消费误区 #

你提到缺失的消息没出现在死信队列，可能是这两个原因：

• 死信订阅未消费：死信主题的消息需要通过订阅拉取才能看到，如果你只创建了死信主题但没建订阅，或者订阅没拉取消息，就会误以为没有消息；
• max_delivery_attempts设置过高：如果该值设为20，PubSub会重试20次才会把消息转到死信，这个过程可能需要几十分钟，你可能在重试完成前就去检查死信了。

排查方式：

• 给死信主题创建订阅，手动拉取消息确认是否存在；
• 调整max_delivery_attempts为较小值（比如3），重新测试，看失败消息是否会快速进入死信。

4. BigQuery表的分区/权限问题 #

如果你的BQ表是时间分区表，而消息的时间戳（或你指定的分区字段）超出了表的分区范围（比如消息时间戳是30天前，而表只保留最近7天的分区），数据会写入对应分区，但你默认查询的是近期分区，就会误以为消息丢失。

另外，要确认PubSub服务账号是否拥有BQ表的bigquery.tables.updateData权限，如果权限不足，写入失败会触发重试，长期权限错误可能导致消息无法正常流转。

5. 监控指标的关键验证 #

一定要利用GCP的监控指标定位流向：

• num_messages_acknowledged：成功写入BQ的消息数，最终应该和总发送数一致；
• bigquery_write_errors：写入BQ失败的次数，能直接反映有多少消息在重试；
• dead_letter_topic_messages_published：发送到死信的消息数，确认是否有消息进入死信；
• num_undelivered_messages：待处理的消息数，直到该值为0，才代表所有消息都已处理完成。

内容的提问来源于stack exchange，提问作者gcp-man