您现在的位置：程式碼之家 >> 編程語言 > >> 更多程式語言 >> 程式設計疑難解答

高併發短信發送架構：Redis 隊列 + 多消費者 Worker 模式

編輯：程式設計疑難解答

問題痛點

同步 HTTP 呼叫運營商 API，高併發下阻塞 Web 執行緒，頻寬/連接數耗盡，大量失敗。
單執行緒 CLI 輪詢發送，延遲高，無法利用多核/頻寬。

推薦架構：生產者-消費者模式

Client (HTTP) 
   → Web Server (PHP) : 驗證 → 寫入 Redis List/Stream (生產者) → 立即返回 "已接收"
   → Worker Processes (PHP CLI / Go / Java) : 多進程/協程 從 Redis 取任務 → 批次/並發呼叫運營商 API → 更新狀態
   → 監控/重試/死信隊列

關鍵設計要點

環節	建議
隊列選型	Redis Stream (5.0+) 最佳：支援消費者群組、確認機制、阻塞讀取。次選 List (LPUSH/BRPOP)。
消費者擴展	啟動 N 個 Worker 進程 (Supervisor/Systemd 管理)，N 根據運營商並發限制與機器核心數調整 (如 10~50)。
批次發送	若運營商支援批次 API，Worker 可 `XREADGROUP COUNT 100` 批次取任務，組裝單次請求，大幅降低 HTTP 開銷。
失敗重試	任務結構含 `retry_count`，失敗重入隊列 (延遲隊列或死信流)，超過閾值入死信表人工介入。
狀態回調	運營商回執/狀態報告 → 獨立 HTTP 端點 → 更新 DB/Redis 狀態 → 推送給客戶端 (WebSocket/長輪詢)。
監控指標	隊列堆積數、發送 QPS、成功率、平均延遲、Worker 存活數。

Windows 環境部署提示

PHP CLI 長運行進程在 Windows 穩定性較差，建議：
① 遷移至 Linux (Docker/WSL2/雲主機)；
② 或用 Go/Rust/Node.js 寫 Worker，跨平台穩健；
③ 必須用 Windows 時，用 NSSM 將 PHP CLI 封裝為服務，配合 ignore_user_abort(true); set_time_limit(0);。