本文为您介绍轻量消息队列（原 MNS）的推送退避策略。
背景信息
在订阅不可用的情况下，为保障整体服务可用性，轻量消息队列（原 MNS）会使用推送退避算法调整向下游订阅方推送消息的速度和数量。根据连续推送失败的次数，对推送间隔时间和单次推送最大条数进行调整：
推送间隔时间：从0逐步扩大至500毫秒，最终达到最大60秒。
单次推送最大条数：从32 条逐渐下降到 1 条。
当轻量消息队列（原 MNS）检测到订阅恢复可用后，会使用快速恢复算法将推送速度和数量在100秒内恢复到初始状态。
在推送退避情况下，重试消息重试间隔会变大，将不再满足重试策略（NotifyStrategy）中的重试间隔和重试次数，通常情况下，推送退避发生后消息的重试次数会变少。建议在该场景中为订阅配置死信队列。
订阅不可用原因
主题向订阅端推送消息时，下列场景可能会出现订阅不可用的情况：
队列：主题订阅的队列不存在，即该订阅的队列被删除。
重要在删除队列之前，请确保该队列未订阅任何正在使用的主题，以免造成业务受损。
HTTP(S)：当向HTTP(S)订阅者连续推送消息失败的次数过多时，轻量消息队列（原 MNS）认为该订阅不可用。
说明您需要在自己的HTTP(S) endpoint处理来自轻量消息队列（原 MNS）推送的POST请求，并返回正确的 HTTP 状态码。
当消息被推送到 HTTP(S) 类型订阅者之后，会根据订阅者返回的HTTP状态码判断是否推送成功，HTTP状态码在 [200, 400) 之间会认为推送成功，其他状态码则被视为推送失败。
注意事项
推送退避机制无法主动启用或停用。
当不可用订阅异常持续时间超过消息保存时长时，超过保存时长的消息会被丢弃（如果设置了死信队列的话会被投递到死信队列）。所以，需要保证订阅者的可用性，或者为订阅配置死信策略。
推送退避机制应用于单个主题下的不可用订阅中的所有消息。