如何配置Pub/Sub客户端实现消息截止时间无限延长

先把几个容易混淆的参数的实际运行逻辑说清楚，官方文档写的太绕，以下是客户端实际运行时的真实行为：

• MinimumAckDeadline：客户端为单条消息申请的单次租约最短时长，不管服务端订阅配置的默认ack deadline是多少，单次申请的租约长度不会低于这个值。
• MaximumAckDeadline：客户端为单条消息申请的单次租约最长时长，每次发起租约延长请求时，申请的时长不会超过这个值。这里要注意，Pub/Sub服务端本身硬限制单次ack deadline最大为600秒（10分钟），设再大服务端也会截断到10分钟。
• DefaultAckDeadline：客户端初始化时如果没能拉取到订阅端的默认ack deadline配置，临时用的兜底初始值，只要客户端能正常连接服务端拉取订阅配置，这个参数基本不会生效。
• MinimumAckExtensionWindow：距离当前租约到期剩余时间小于这个值时，客户端会强制触发租约延长，不管之前的调度逻辑是什么，避免网络抖动、请求延迟导致租约过期。
• DefaultAckExtensionWindow：正常调度下，客户端会在租约剩余时间等于这个值的时候，提前发起延长请求。
• MinimumLeaseExtensionDelay：同一条消息两次租约延长请求之间的最小间隔，防止客户端短时间内发太多modifyAckDeadline请求打满配额。
• DefaultMaxTotalAckExtension：单条消息从被客户端接收开始，自动延长租约的总时长上限，超过这个时间后客户端不再主动延长，消息会被服务端判定为未确认，触发重复投递。

针对数天级处理场景的具体配置 #

你一开始想把DefaultMaxTotalAckExtension设到数天的思路是对的，直接按业务上单条消息的最大预估处理时长上浮20%设置就行，比如最长处理需要3天就设为86小时，留足冗余避免正常处理时触发超时重投。

关于AckDeadline相关参数的调整：不用改MinimumAckDeadline和DefaultAckDeadline，只需要把MaximumAckDeadline设为600秒即可。

• 改DefaultAckDeadline没有意义，正常连接服务端后这个值不会被用到。
• MinimumAckDeadline保持默认的10秒即可，设太高反而会在客户端真的崩溃退出时，服务端需要等更久才能把消息重投给其他健康节点，拉长故障恢复时间。
• 设MaximumAckDeadline为600秒刚好卡到服务端支持的单次租约上限，既能尽可能减少租约延长的请求次数，也能保证每10分钟客户端就会给服务端发一次存活证明，服务端能正常感知客户端在线。

剩下的三个扩展窗口相关参数，全部保持默认值就可以，不需要额外调整：

• 默认配置下DefaultAckExtensionWindow是单次租约时长的50%，对应600秒租约就是剩余300秒时发起延长，足够覆盖网络延迟、接口限流等异常情况。
• 默认MinimumAckExtensionWindow是单次租约时长的10%，对应600秒租约就是最晚剩余60秒时强制发延长请求，不会出现租约意外过期的问题。
• 默认的MinimumLeaseExtensionDelay会把延长请求的频率控制在合理范围，既不会打满配额，也不会影响租约续期逻辑。

额外提醒：不要把DefaultMaxTotalAckExtension设为无限大，按实际最大处理时长留冗余即可，避免客户端进程卡死在某条异常消息上时，消息永远不会被重投到其他节点处理。

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