無論您是想開發新的應用程式 還是已經在用高流量服務 本指南將提供豐富的洞察資訊與建議，協助您瞭解如何調度資源 與 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 通知， 而非套用伺服器端節流如下所示：
- 所有客戶是否需要在 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。