無論您是想開發新的應用程式 還是已經在用高流量服務 本指南將提供豐富的洞察資訊與建議,協助您瞭解如何調度資源 與 FCM 合作這些概念和做法有助於避免 在需要傳送大量郵件時會受到影響。
重要詞彙及概念
訊息要求:FCM 訊息要求。可與「request」交替使用 「message」或「query」。
每秒要求數 (RPS):這項指標會說明傳入速率的指標 傳送至 FCM;可與每秒查詢次數 (QPS) 交替使用。
配額權杖、權杖值區與補充:傳送訊息或 FCM HTTP v1 API,每項要求在特定時間都會耗用分配給配額的配額權杖 視窗。這個視窗稱為「權杖值區」,在結尾重新供應 時間範圍舉例來說:HTTP v1 API 每個 API 分配到的配額符記 60 萬 1 分鐘的權杖值區,會在每 1 分鐘的時長結束時補充至已滿。
伺服器端節流:流量超過 FCM 服務的
容量超過服務規模的要求會遭到拒絕,再輸入頻率限制輸入
流程系統可能會傳回 429
個含 retry-after
標頭的錯誤回應,藉此指出
您應該等待指定的時間範圍才能重試要求。
用戶端節流:當用戶端觀察到要求失敗、高延遲時
或 429
錯誤時,應主動限制輸出流量,以免誇大輸出流量
壅塞程度。
指數輪詢: 重試錯誤時,將延遲時間大幅增加。例如:1 秒 2s、4s、8s、16s、32 秒。
Jittering:避免以確切的間隔重試要求。使用時基誤差 您會透過隨機程序改變重試延遲,統一分配延遲時間 (例如:0.9 秒、2.3 秒、4.1 秒、8.5 秒、17.9 秒、34.7 秒)。
重試次數限制:在無指數的情況下重試失敗的要求時 時,這些容器通常會累積並添加持續性流量負載 可能會「放大」並加劇了交通壅塞問題
問題:流量突然激增
FCM 每秒可處理數百萬個要求 (RPS)。無論是 系統性壅塞、延遲問題和服務中斷等都是流量高峰。
什麼是尖峰流量?
有數種不同類型的流量高峰。
每小時高峰:FCM 在前 30 天的流量超過一倍 每小時到 2 分鐘。同理,儘管數量較少,高峰也同樣是 會在半小時和四分之一時觀察到現象 (例如:00:15、00:30、00:45)
重試增強:重試失敗或逾時的要求,而不重試 指數輪詢可以 在現有流量高峰之外,逐漸累積一波又一波的流量。
突然出現流量模式變更:將新流量導向 FCM 或移動流量 將重點放在所有 FCM 的應用,卻沒有平滑的適應期 可能造成用量升高
優先載入配額權杖用量:一開始即用完所有配額權杖 配額,而不是讓要求平均分散在配額中 窗口會引發開關作用,但成本高昂且費用高昂 負載平衡
特殊活動:節日 (跨年夜) 或運動賽事期間達到高峰 (FIFA 世界盃足球賽)。
修復流量暴增為「整併曲線」
本節說明在下列情況下, 「簡化曲線」的策略
FCM">只將「FCM」用於適當用途
在某些情況下,使用 FCM 通知無法傳送通知 或適當。
舉例來說,如要接收日曆活動通知,你可以在以下時間排定當地工作的時間: 您的應用程式,而非傳送 再從應用程式伺服器載入該映像檔限制 FCM 訊息只能在日曆同步處理時使用。
避免高點
其中一個擴充反模式的其中一項,就是盡快傳送 FCM 通知, 而非套用伺服器端節流如下所示:
- 所有客戶是否需要在 1 分鐘內收到相同的通知?比方說,是否仍有 5 分鐘的送達時間,仍能滿足您的業務需求?
- 是否可以根據優先順序區隔客戶,以便於高點過高峰?
- 您是否可以提前安排通知?
盡可能:避免使用會導致 FCM 傳送配額立即耗盡的策略,只有在權杖值區重新填入後,才要重複該模式。這項存取權 會導致 FCM 及其相依的負載平衡問題 有些人會將 Cloud Storage 視為檔案系統 但實際上不是請盡可能逐漸增加流量。最低坡度為 0,坡道為 0 也就是 RPS 的最高值優先使用較長的視窗 每秒要求數
避免「準時」路況
可能的話:請避免在每段時間的 2 分鐘內傳送郵件 分別以 :00、:15、:30 和 :45 分鐘表示。
實作伺服器端節流
實作伺服器端節流,監控及管理進入 FCM 的流量。
處理重試
FCM 努力維持高可用性,但有時可能會逾時 還是失敗雖然原因各不相同,但下列最佳做法能幫您解決問題,請重試 應用程式能盡快傳送訊息,同時將對 壅塞程度
逾時
建議您設定至少 10 秒的傳送要求逾時時間 重試中。FCM 的內部遠端程序呼叫大多使用 10 秒鐘的逾時。
錯誤
- 針對 400、401、403、404 錯誤:取消且不要重試。
- 429 錯誤:等待一段時間後重試的重試次數 標題。如未設定重試後標頭,預設值為 60 秒。
- 如果是 500 錯誤:請以指數輪詢方式重試。
指數輪詢
如要避免重試擴大,請實作指數 以及重試要求的時基誤差。Firebase Admin SDK 實作指數輪詢
以下提供幾項建議設定:
- 最小間隔:不要立即透過 FCM 重試失敗的要求。請至少等待 10 秒,再重試失敗的要求。
- 間隔上限:設定不再及時捨棄要求的時間間隔上限,而非無限期重試。
如果要求持續以指數輪詢方式重試,且要求仍未超過 60 分鐘後失敗,可能是因為系統錯誤歸類為可重試錯誤;或 FCM 發生服務中斷,可能導致重試作業意外加劇 或預測結果
建立推出和復原方案,以及逐步變更
進行大規模流量變化時,例如將流量增加到 FCM 或 在不同區域或網路之間轉移流量、設計推出/復原計畫 並逐步實施這項異動可保護使用者、您的服務和 FCM。
- 發布計畫可以滿足利害關係人期望。在某些情況下 (如下所述),建議您事先與 FCM 團隊分享推出計畫,以免發生意外情況。
- 復原計畫可讓您考量各種因應措施,並準備相關機制,以便在意外故障時快速安全地復原。
- 逐步變更有兩個層面:
- 「Step-wise」增加量:步數應為 1% ->5% ->10% ->25% ->50% ->75% ->100% 以上。「肥皂」(觀察負載下的系統行為),持續 1 天到 1 週。讓您在下一次「換機」前,先找出潛在問題
- 逐步增加流量:每次採取「步驟」時,讓流量分散在至少一小時內順暢無阻。這讓 FCM 的負載平衡基礎架構能適當調整新流量,同時降低無線基地台和壅塞的可能性。
以下假設情境是將全球 500,000 個 RPS 從全球 FCM 舊版 HTTP API 到 FCM HTTP v1 API:
週 | 步驟 | 逐步適應期 |
---|---|---|
0 | 1% 適應期 | 在一小時內流暢地從 0 至 5,000 RPS 變成 FCM HTTP v1。 |
1 分 | 5% 適應期 | 調整速度在 2 小時內從 5,000 到 25,000 RPS 流暢。 |
2 分 | 10% 適應期 | 順暢適應 2 小時,從 25,000 至 50,000 RPS 順暢運作 |
3 | 25% 適應期 | 逐漸增加 3 小時,從 50,000 到 125,000 RPS |
4 分 | 50% 適應期 | 逐步增加 6 小時,從 125,000 到 250,000 RPS |
5 分 | 75% 適應期 | 逐步增加 6 小時,從 250,000 到 375,000 RPS |
6 | 100% 適應期 | 從 6 小時內 375,000 至 500,000 RPS 逐漸增加 |
假設復原計畫:
- 如果 95 個百分位數的延遲時間增加到超過 500 毫秒,或者任何步驟的錯誤率超過 1%,且持續超過一小時,請使用動態設定立即復原至上一個步驟。
- 繼續復原至先前步驟,直到延遲和錯誤率恢復成名程度。
聯絡 FCM 的時機
透過 Firebase 支援團隊與 FCM 聯絡 符合下列任一條件:
- 預設配額已不符合您的用途需求
- 您即將在 3 個月期間變更郵件傳送模式,時間: 全球 RPS 為 100,000 或 30,000 RPS。