Kafka 實務坑筆記（七）：雙十一大促的生死時刻

問題現象

雙十一當晚，監控系統顯示：

• 兩個 Consumer Group 的 Lag 怎樣都降不下來
• 91APP 的 Queue 卡到 30 個以上
• Job 機不斷報 OOM（記憶體不足）

問題分析

各平台 API 響應時間實測

問題一：91APP API 不穩

整點 Job 拉取已完成和已出貨訂單時：

• 訂單量大導致 API 響應時間接近 5 分鐘門檻
• 逼近 Kafka Session Timeout
• API 不穩時甚至超過 5 分鐘

問題二：記憶體爆炸

統計 Job 需要從 Solr 拉取訂單資料：

• 雙十一訂單量暴增
• 一次拉了將近 6,000 張訂單的完整資料
• 記憶體直接爆炸 → OOM

解決方案

問題一：API 超時

1. 增加 Kafka 的 Timeout 設定
2. 分批處理訂單
3. 加入 Circuit Breaker（斷路器）

問題二：記憶體優化

// 修改前：拉取全部欄位
query.setFields("*");

// 修改後：只拉取需要計算的欄位
query.setFields("id", "amount", "status", "created_at");

同時將 Job 機記憶體從 1GB 提升到 2GB。

關鍵數據

雙十一的量，最好預估平常的 10~15 倍，免運真的很吸引人！

容量規劃建議

大促前檢查清單

1. ✅ 各平台 API 響應時間測試
2. ✅ 壓力測試（10 倍流量）
3. ✅ 記憶體使用量監控
4. ✅ Queue Lag 告警設定
5. ✅ 緊急擴容方案準備