GCloud Pub/Sub未确认消息存储机制及死信队列相关疑问

一、未确认消息的基础处理逻辑 #

• 订阅者未确认消息时，Pub/Sub会在确认超时时间（可配置，默认10分钟）后将消息重新投递给订阅者。
• 你提到的免费存储未确认消息最长7天，这是订阅的消息保留时长——不管消息是未确认还是已确认但未过期，只要在这个时长内都会被存储。多次投递失败的消息只要还在7天保留期内，就会继续尝试投递，直到超过保留期被删除，或者被转发到死信队列。

二、付费死信队列的作用 #

死信队列（DLQ）的核心价值是隔离无法正常处理的消息，解决“无限重复投递”的问题：

• 当消息投递次数达到你设置的最大尝试次数后，Pub/Sub会将消息转发到死信队列，不再继续投递给原订阅者，避免这些异常消息占用订阅的投递资源。
• 你可以单独处理死信队列里的消息，比如排查处理失败原因、修复后重新投递，或者归档清理。
• 免费的7天保留只是存储消息，但不会停止重复投递，死信队列能从根源上终止无效投递，同时保留异常消息用于排查，这是它不可替代的作用。

三、启用死信队列但未勾选消息保留选项的相关问题 #

• 死信队列本质是独立的订阅/主题，它的消息保留设置独立于原订阅。如果未勾选死信队列的消息保留选项，会继承对应主题的保留时长（默认7天，可配置）。
• 原订阅的消息保留和死信队列的存储不重复：原订阅里的消息被转发到死信队列后，会从原订阅的未确认消息列表中移除；死信队列存储的是已经达到投递上限的消息，两者对应不同状态的消息，不存在重复存储的情况。

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