GCP Pub/Sub订阅偶现消息延迟60秒问题排查求助

问题现象 #

系统周期性出现严重异常：使用GCP Pub/Sub时，订阅者有时会收到延迟整整1分钟的消息。

异常时显著飙升的指标 #

• oldest_unacked_message_age
• delivery_latency_health_score.expired_ack_deadlines = 0
• expired_ack_deadlines_count

订阅与系统备注信息 #

• unacked_messages_count指标未飙升，系统负载正常
• 已确认延迟消息成功发布到Pub/Sub，且publish_time属性正确
• 其他所有指标显示系统未过载，订阅者仍在正常拉取其他消息
• 订阅者启动消息处理时会打印日志，以此确认消息延迟情况

使用的客户端与拉取方式 #

使用google-cloud-pubsub、spring-cloud-gcp-pubsub、proto-google-cloud-pubsub-v1及spring-integrations客户端库，通过gRPC协议以StreamingPull方式拉取消息。

疑问点 #

• 原假设消息若因瞬时故障丢失，按确认超时设置应在10秒内重发，是否正确？

  更新：延迟60秒到达的消息带有属性googclient_deliveryattempt=1，据理解这表示并非重发消息？

• 曾怀疑问题出在modifyAckDeadline请求，但未做任何自定义覆盖，客户端库默认使用DEFAULT_MAX_ACK_EXTENSION_PERIOD = 0

  更新：发送的StreamingPullRequest中StreamAckDeadlineSeconds设为60，该值由客户端库的STREAM_ACK_DEADLINE_DEFAULT（默认60）初始化。但StreamingPullRequest中的注释说明：We need to set streaming ack deadline, but it's not useful since we'll modack to send receipt. Set to some big-ish value in case we modack late

期望与求助 #

期望订阅者能在消息发布后立即接收，或在故障/丢失后按确认超时（10-20秒）重发，而非延迟60秒，恳请提供排查解决建议。

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