無論是要開發新的應用程式，還是已經在執行高流量服務，本指南都會提供深入分析結果和建議，協助您瞭解如何使用 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 個每秒要求數。