在現代行動互聯網與企業級 SaaS 系統中，推播通知系統（Notification System） 是維繫使用者活躍度、傳遞關鍵交易狀態與安全警報的核心通道。
一個成熟的推播系統，絕不是在業務程式碼中簡單呼叫一下第三方 SDK 那樣簡單。面對數千萬至數億的使用者規模，推播平台必須解決一系列複雜的架構挑戰：
- 跨多管道統一路由：如何協調 iOS（Apple APNs）、Android（Google FCM）、瀏覽器（Web Push）、站內即時 WebSocket、以及作為兜底的 SMS 簡訊與 Email？
- 防轟炸與勿擾模式（DND）：如何在深夜自動聚合行銷推播，防止使用者被頻繁打擾而解除安裝 App？
- 海量併發削峰與去重：百萬級行銷廣播如何防止衝垮後端網路？如何防止因重試導致使用者收到多封重複的驗證碼？
- 優先級隔離：高優先級的 2FA 驗證碼與交易扣款通知，如何避免被海量的雙十一行銷促銷推播卡死在隊列中？
本文將全景拆解生產級推播系統的完整架構設計與底層關鍵模組。
1. 現代統一推播通知系統全鏈路架構
2. 核心底層推播管道特性解析
| 推播管道 | 底層協定 | 連線管理 | 延遲特性 | 成本與限制 |
|---|---|---|---|---|
| 1. Apple APNs | HTTP/2 over TLS | 長連線池 (JWT 授權) | 極低 (毫秒至數秒) | 免費，Payload ≤ 4KB |
| 2. Google FCM | HTTP v1 / JSON | 長連線池 | 極低 (毫秒至數秒) | 免費，Payload ≤ 4KB |
| 3. In-App WebSocket | TCP / WSS | 自建 Gateway 叢集 | 實時 (< 100ms) | 伺服器長連線記憶體 |
| 4. SMS 簡訊 | SMPP / HTTP REST | 第三方運營商中繼 | 1 ~ 5 秒 | 高昂 (按條計費) |
| 5. Email 郵件 | SMTP / API | 批次郵件發送服務 | 數秒至數分鐘 | 需防垃圾郵件評分 |
2.1 Apple APNs 的 HTTP/2 極致連線優化
早期 APNs 採用二進位 Socket 協議，當連線出錯時會直接關閉連線。現代 APNs 採用標準 HTTP/2 協議：
- 支援在單一 TCP 連線上進行多路復用（Multiplexing），平行發送成千上萬個推播請求。
- 採用 Token-based 認證（ES256 簽名的 JWT），取代了老舊每年過期的
.p12證書，實現了零停機無感憑證輪換。
3. 防騷擾與流量治理四大核心機制
3.1 冪等去重機制（Deduplication）
為了防止因網路重試或業務 Bug 導致使用者連續收到多則相同推播：
- 在網關層計算去重雜湊鍵：
dedup_key = "notify:dedup:" + SHA256(user_id + template_id + unique_biz_id)。 - 使用 Redis 的
SET dedup_key "1" NX EX 300進行原子佔位。若 Key 已存在，直接拒絕重複請求。
3.2 勿擾模式（Do-Not-Disturb）與智慧聚合
- 時區自適應：根據使用者的地理時區，若當前時間處於夜間勿擾區間（例如
22:00 ~ 08:00）：- P0 級關鍵通知（如帳號被盜異地登入）：無視 DND，強制即時送達。
- 非關鍵行銷推播：暫存於 Redis / DB 的延時桶中，在隔日早上 08:30 以單一匯總摘要（Daily Digest） 的形式合併發送。
3.3 頻率限制（Rate Limiting）
- 針對單一使用者設定配額：例如「每位使用者每小時最多接收 3 則非關鍵推播，每日上限 10 則」，超出配額的低優先級訊息直接靜默拋棄。
4. 故障容錯與多管道降級策略
當主要通道受阻時，系統必須具備自動降級與狀態追蹤能力：
5. 架構總結
一個生產級的現代推播通知系統，本質上是一個高可靠、低延遲的智慧事件調度中心：
- 透過 優先級隊列 徹底隔離核心業務與行銷流量；
- 透過 去重、DND 聚合與頻率限制 提供優質的使用者體驗；
- 透過 HTTP/2 連線池與多管道降級矩陣 確保關鍵訊息在極端環境下 100% 可靠送達。