Simple Message Queue (formerly MNS)對超過限流閾值的請求執行限流策略，從而避免底層資源承受過高壓力。瞭解限流策略有助於合理規劃訊息收發頻率，並在觸發限流時採取正確的應對措施。
限流行為
當流量接近或達到限流閾值時，服務端會根據即時資源水位自動彈性調整限流閾值，在多數情境下，可動態支撐更高並發請求且使用者無感知。若觸發臨時限流（如突發峰值激增、叢集資源瓶頸等），系統將在自動擴容完成後恢複流量處理能力並同步提升限流閾值。
當觸發限流報錯時，系統將啟動反壓機制，此時超出閾值的請求會在服務端被短暫掛起後返回 429（TooManyRequests）錯誤，掛起時間長度由服務端根據即時負載動態調整，通常在 10~500 毫秒之間，最大不超過 5 秒。避免系統因過載而影響整體效能和穩定性。
錯誤碼
觸發限流策略後，Simple Message Queue (formerly MNS)服務端會返回如下錯誤碼資訊。
HTTPS 狀態代碼 | 錯誤碼 Code | 錯誤描述資訊 Message |
429 | TooManyRequests | The request is denied by cluster flow limiter for too many requests. |
限流閾值說明
隊列 消費模式下的異常消費限流策略
在標準的隊列消費模式中，用戶端在成功處理訊息後，應在服務端刪除該訊息。如果用戶端大量出現“只接收訊息，但不發送刪除訊息請求”的非標準行為，系統將視其為異常消費，並觸發限流機制以保障系統穩定性。限流後，用戶端接收新訊息的速度會大幅降低。
觸發限流的閾值（滿足任一條件即可）：
期間：該異常消費持續超過 30 分鐘。
訊息數量：累計接收但未刪除的訊息總量達到 5000 條。
流量速率：接收但未刪除的瞬時速率超過 1,000 TPS。
大流量請求的限流策略
每個主帳號每個地區限流閾值預設值：20000 TPS。如果流量已超過 20000 TPS，可登入配額中心控制台申請提高單地區 TPS 上限，操作步驟請參見建立配額提升申請。
請求次數計數說明如下：
每調用 API 介面 1 次，計為 1 次請求。
批量發送情境 TPS 計算：當使用 BatchSendMessage 介面請求某隊列時，BatchSendMessage 的 TPS = BatchSendMessage 每秒實際請求次數×介面中的訊息條數。例如，BatchSendMessage 介面 1 秒鐘實際請求次數是 100，介面中包含 10 條訊息，則佔用單個隊列 TPS=100×10 = 1000。
批量消費情境 TPS 計算：當使用 BatchReceiveMessage 介面請求某隊列時，BatchReceiveMessage 的 TPS = BatchReceiveMessage 每秒實際請求次數（與批量訊息條數無關）。例如，BatchReceiveMessage 介面 1 秒鐘實際請求次數是 100，介面中包含 10 條訊息，則佔用單個隊列 TPS=100。
避免限流影響
為避免限流策略對業務的影響，建議關注以下兩方面：