本文將說明如何妥善處理大量傳送至 webhook 的訊息。Business Messages 平台已準備好在許多不同情況下投入實際運用。如果您預期會發生特定事件，我們的支援團隊也可以協助您做好準備。您可以採取幾個簡單步驟，讓 webhook 更穩健。
使用者至 webhook 的流量
針對使用者至 webhook 的流量，請考量您希望自家業務的流量模式為何。您是否預期會出現任何「突發」模式，或訊息量突然改變？舉例來說，如果餐廳只提供晚餐，可能會在晚上收到許多訊息，但在其他時間收到的訊息不多。舉另一個例子來說，如果商店正在放送特別促銷活動，則在宣傳活動時，可能會收到異常大量的訊息。
一般來說，Google 基礎架構可處理突然激增的流量。商務訊息使用與 Gmail 和 Google Cloud 等大型產品相同的伺服器資源。Webhook 的訊息量不太可能會過高，導致 Business Messages 發生故障。此外，Business Messages 會將每位服務專員的訊息分開排入佇列。如果某個代理程式的訊息佇列壅塞，其他代理程式就不會受到影響，即使這些代理程式共用相同的 webhook 也一樣。
不過，這項功能僅適用於商務訊息基礎架構中的訊息佇列。訊息傳送至 Webhook 後，情況就不同了。您應確保 webhook 可視需要進行擴充，例如實作佇列、並行處理要求等。如果 webhook 以 HTTP 500 回應訊息，或是完全無法回應，Business Messages 會以指數方式降低 webhook 的訊息傳送率。訊息會在佇列中保留 7 天。如果 webhook 未在該時間內回應 HTTP 200，Business Messages 就會捨棄訊息。
Webhook 到使用者流量
透過 webhook 傳送的訊息應遵循每個對話限制每分鐘 60 則訊息的規定。合法的訊息流程不太可能達到這個配額，但您應準備好處理商家訊息傳送的 HTTP 429 錯誤，這表示您已超過配額。
一般來說，如果 webhook 從 Business Messages 收到 HTTP 429 或 HTTP 500，表示發生暫時性錯誤，可能與訊息傳送頻率有關。您應以指數輪詢策略重試這些訊息。不過，如果 webhook 收到 HTTP 503 或 HTTP 4xx (除了 HTTP 429)，請立即停止重試，並通知我們的支援團隊。這些錯誤代碼可能表示 Business Messages 基礎架構出現問題 (例如拒絕服務事件)，傳送更多訊息只會使問題更加嚴重。
雖然沒有特定的停權標準可用於處理超出訊息配額的問題，但 Business Messages 可能會將行為異常或傳送過多訊息的服務專員停權。請詳閱停權條件，確保您的服務專員遵守必要標準。
如何取得協助
建議您在預期發生問題時立即與我們聯絡。如果您預期會出現極高流量，例如廣告宣傳力度極高的促銷活動，我們可以啟動額外的放送資源，盡可能做好準備。不過，在大多數情況下，您不需要採取這類措施。
如果您遇到訊息載入問題，也可以與我們聯絡，我們會盡力協助您解決問題。