GCP Pubsub引发并发问题：为何K8s多Pod重复消费Pull Subscription同一条消息

• 确认超时（Ack Deadline）配置不当：Pull Subscription的机制是消费者拉取到消息后，服务端会临时锁定该消息，等待消费者返回确认（Ack）。如果最先拉取到M1的P1处理耗时超过了配置的Ack Deadline时长，服务端会判定消息处理失败，自动解锁并重新投递给同订阅下的其他消费者，就会出现P2、P3也拉到M1的情况。
• 消费模式配置错误：部分消息队列产品的Pull Subscription支持广播/集群两种消费模式，若误配置为广播模式，同个订阅下的所有消费者都会收到全量消息，每一条消息自然会被所有Pod拉取到。
• 消费端确认逻辑异常：P1处理完M1后，未成功调用ack接口通知服务端删除消息，或者调用ack时出现网络波动、异常未重试，导致服务端未收到确认信号，触发重试投递规则将消息发给其他Pod。
• 批量拉取参数不合理：若单次Pull请求设置的拉取消息数超过单Pod的处理能力，部分被拉到P1本地的消息还没来得及处理就超过了Ack Deadline，也会被服务端重新投递给其他Pod。

• 调整Ack相关配置：根据业务实际最大消息处理时长，设置合理的Ack Deadline值；处理长耗时消息时，可主动调用modifyAckDeadline接口延长单条消息的锁定时长，避免未处理完就被服务端回收。
• 确认消费模式配置：将Pull Subscription PS1的消费模式明确设置为集群消费（共享消费），保证同一条消息只会被投递给订阅下的一个消费者实例。
• 优化消费端确认逻辑：为ack调用增加重试机制，捕获网络异常等可重试错误多次尝试上报，只有确认ack成功后才结束当前消息的处理流程。
• 调整批量拉取参数：根据单Pod的处理吞吐量，合理设置max_messages_per_pull参数，避免单次拉取过多消息无法在Ack Deadline内处理完成。
• 业务侧增加幂等校验：核心业务逻辑通过消息唯一ID做幂等判断，即使出现极端场景的重复投递，也能直接丢弃重复消息，避免业务逻辑重复执行。

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