無論是要開發新的應用程式,還是已經在執行高流量服務,本指南都會提供深入分析結果和建議,協助您瞭解如何使用 FCM 順利調度資源。當您需要傳送大量郵件時,這些概念和做法可以協助您避免受到負面影響。
重要詞彙及概念
訊息要求:FCM 訊息要求,可與「request」、「message」或「查詢」交替使用。
每秒要求數 (RPS):這項指標會說明傳入 FCM 的要求比率,可與每秒查詢次數 (QPS) 交替使用。
配額權杖、權杖值區和補充作業:透過 FCM HTTP v1 API 傳送訊息時,每個要求都會在特定時間範圍內耗用分配到的配額權杖。這個視窗稱為「權杖值區」,在時間範圍結束時「重新執行」可完全用盡。舉例來說,HTTP v1 API 每 1 分鐘權杖值區會分配 60 萬個配額符記,這個符記會在每個 1 分鐘期間結束時補充為完整狀態。
伺服器端節流:如果流量超過 FCM 服務的容量,超出服務容量的要求就會遭拒,以實施頻率限制輸入流程。系統可能會傳回包含 retry-after
標頭的 429
錯誤回應,指出您應該等待指定時間範圍後再重試要求。
用戶端節流:當用戶端觀察到要求失敗、高延遲或 429
錯誤時,應主動限制輸出資料流,以免加劇壅塞。
指數輪詢:重試錯誤時,加入指數會逐漸增加的延遲時間。例如:1 秒、2 秒、4 秒、8 秒、16 秒、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 通知,而不是套用伺服器端節流。如下所示:
- 所有客戶是否需要在 1 分鐘內收到相同的通知?比方說,是否仍有 5 分鐘的送達時間,仍能滿足您的業務需求?
- 是否可以根據優先順序區隔客戶,以便於高點過高峰?
- 您是否可以提前安排通知?
盡可能:避免使用會導致 FCM 傳送配額立即耗盡的策略,只有在權杖值區重新填入後,才要重複該模式。此存取模式會為 FCM 及其相依系統創造負載平衡問題。請盡可能逐漸增加流量。至少將 0 個 RPS 從 0 提升到 60 秒的時間範圍上限。最好使用較長的時段,適合較高的每秒要求數。
避開「每小時」流量
盡可能:請避免在每個分鐘標記 :00、:15、:30 與 :45 分鐘之間傳送訊息。
實作伺服器端節流
實作伺服器端節流,監控及管理進入 FCM 的流量。
處理重試
雖然 FCM 努力維持高可用性,但有時某些要求會逾時或失敗。雖然原因各不相同,但下列最佳做法能最佳化重試行為,以便盡快傳送訊息,同時盡量降低對流量壅塞的影響。
逾時
請先設定傳送要求的逾時時間至少設為 10 秒,然後再重試。FCM 的內部遠端程序呼叫大多使用 10 秒鐘的逾時。
發生錯誤
- 針對 400、401、403、404 錯誤:取消且不要重試。
- 429 錯誤:等待在重試後標頭中設定的持續時間後重試。如未設定重試後標頭,預設值為 60 秒。
- 如果是 500 錯誤:請以指數輪詢方式重試。
指數輪詢
為避免重試擴大,請在重試要求的時基誤差實作指數輪詢。例如 Firebase Admin SDK 則會實作指數輪詢。
以下提供幾項建議設定:
- 最小間隔:不要立即透過 FCM 重試失敗的要求。請至少等待 10 秒,再重試失敗的要求。
- 間隔上限:設定不再及時捨棄要求的時間間隔上限,而非無限期重試。
如果要求在 60 分鐘後持續重試,且在 60 分鐘後仍失敗,則系統會將其誤分類為可重試錯誤;或者 FCM 發生服務中斷,導致重試作業無意中過載情況。
建立推出和復原方案,以及逐步變更
進行大規模流量變更時 (例如增加 FCM 流量或跨區域或網路轉移流量),設計推出/復原計畫並導入逐步變更,可以保護您的使用者、服務和 FCM。
- 發布計畫可以滿足利害關係人期望。在某些情況下 (如下所述),建議您事先與 FCM 團隊分享推出計畫,以免發生意外情況。
- 復原計畫可讓您考量各種因應措施,並準備相關機制,以便在意外故障時快速安全地復原。
- 逐步進行變更有兩個層面:
以下是將全球 500,000 個 RPS 從 FCM Legacy 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% 適應期 | 逐步增加從 125,000 至 250,000 RPS 超過 6 小時 |
5 | 75% 適應期 | 逐步增加從 250,000 到 375,000 RPS 超過 6 小時 |
6 | 100% 適應期 | 逐步增加從 375,000 至 500,000 RPS 超過 6 小時 |
假設復原計畫:
- 如果 95 個百分位數的延遲時間增加到超過 500 毫秒,或者任何步驟的錯誤率超過 1%,且持續超過一小時,請使用動態設定立即復原至上一個步驟。
- 繼續復原至先前步驟,直到延遲和錯誤率恢復成名程度。
聯絡 FCM 的時機
如果遇到下列任一情況,請透過 Firebase 支援團隊與 FCM 聯絡:
- 預設配額已不符合您的用途需求
- 您在 3 個月內,以 100,000 RPS 為上限,在全球變更傳送模式,或同時變更每秒 30,000 個每秒要求數。