可預期突發

事前知道流量會增加，有時間準備。

可預期突發的應對核心是容量預備 — 活動前擴容、活動後縮回。

預備清單

不可預期突發

事前不知道流量會增加，只能靠架構設計吸收。

不可預期突發的應對核心是降級 — 系統在超載時自動犧牲非核心功能，保住核心功能。

監控系統的 error storm

Error storm 是監控系統特有的突發場景：被監控的 app 出了 bug，每個受影響的使用者都在送 error 事件。如果有 10 萬使用者同時遇到同一個 bug，collector 瞬間收到 10 萬筆 error 事件。

Error storm 的矛盾：error 事件是 debug 最需要的資料，但 storm 時的大量 error 可能打垮 collector。處理策略是保留前 N 筆完整 error（含 stack trace）、後續的 error 只計數不存原始資料。第一筆 error 的 stack trace 足夠 debug，後續的 10 萬筆只是確認影響範圍。

下一步路由

• 突發時的降級策略 → 降級策略
• Queue 做 burst 緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表

動態取樣

流量超過閾值時自動降低取樣率。平時 100% 收集、超載時降到 10% — 仍有資料可分析，只是精度下降。

觸發條件

取樣的公平性

動態取樣不應該只丟新事件保留舊事件（FIFO 丟棄）— 這會讓取樣偏向「burst 初期的事件」。更好的策略是隨機取樣（每個事件有 sampling_rate 的機率被保留），讓取樣後的資料仍然能代表整體分佈。

取樣後的事件帶 _sampling_rate 欄位，分析時用 1 / sampling_rate 做加權還原。

事件優先級

不同事件類型的 debug 價值不同。超載時先丟價值低的，保留價值高的。

優先級的判斷原則：「這個事件丟了、要花多少時間從其他來源補回相同資訊」。Error 的 stack trace 丟了幾乎不可能從其他來源補回；event 的 click 計數可以從後續資料的趨勢推測。

功能降級

非核心功能暫時關閉或降低更新頻率，把資源留給核心功能。

降級的觸發和恢復應該自動化 — 用 collector 的內部 metric（goroutine pool 使用率、寫入延遲）作為訊號。

聚合前移

讓 SDK 端做預聚合，減少送到 collector 的事件數量。

平時：每次 click 送一筆 button.clicked 事件 → 100 次 click = 100 筆事件。 聚合前移：SDK 累積 10 秒內的 click → 送一筆 button.clicked 帶 count: 17 → 100 次 click = ~10 筆事件。

聚合前移犧牲的是事件粒度（失去每次 click 的精確時間戳），換取的是 10x 的事件量減少。適用於高頻但單筆資訊量低的事件（click、scroll、mousemove）。

聚合前移的觸發也可以是動態的 — collector 回 429 時 SDK 自動啟用聚合前移，流量恢復後關閉。

下一步路由

• 突發流量的分類 → 突發流量的分類
• Queue 做更大規模的緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表
• 背壓和 rate limit 的基礎 → 模組三 流量管控

為什麼不直接寫 DB

直接寫 DB（SQLite / PostgreSQL）的問題是 ingestion 速度被 DB 寫入速度限制。DB 寫入慢（鎖定、WAL flush、索引更新）時，HTTP handler 的 goroutine 等在 Storage.Store() 上 — goroutine 積壓 → 記憶體上升 → 最終 OOM 或 response timeout。

Queue 的解決方式是把「接收」和「寫入」分開：接收端只做 JSON 驗證 + 寫入 queue（微秒級），處理端從 queue 讀取 + 寫入 DB（毫秒級）。接收端的吞吐量不再受 DB 限制。

取捨

自用工具場景不需要 queue — 單 collector + SQLite 的直接寫入足夠。Queue 的引入條件是「直接寫 DB 的背壓開始頻繁觸發」。

候選類型

選型判斷

已有 Redis → 先用 Redis Streams（零新增元件）。Go 為主的技術棧 → NATS JetStream（Go 原生 client、單 binary 部署）。需要跨消費者群組或日誌級持久化 → Kafka。

引入條件

Queue 的引入是架構複雜度的顯著上升（一個元件變三個）。明確的觸發條件：

• 背壓（429 回應）頻繁觸發（每天 > 100 次）且持續（不只是瞬間 burst）
• 寫入延遲的 P95 超過 500ms（DB 成為瓶頸）
• 需要多個 consumer（同一批事件要送到不同的下游 — analytics DB、alert engine、archive）

監控系統的 Queue 架構

1SDK ──→ Collector (ingestion only)
2           │
3           ├─ 驗證 JSON Schema
4           ├─ Redaction
5           └─ 寫入 Queue
6                 │
7                 ├── Worker A → PostgreSQL（主 storage）
8                 ├── Worker B → 降採樣 → Summary tables
9                 └── Worker C → Rule engine → Alert

Collector 瘦身為 ingestion-only — 只做接收、驗證、redaction 和寫入 queue。Storage 寫入、降採樣、rule engine 都移到 worker 群。Collector 的吞吐瓶頸從 DB 寫入變成 queue 寫入（queue 的寫入吞吐通常是 DB 的 10-100 倍）。

下一步路由

• 突發流量的分類 → 突發流量的分類
• 降級策略 → 降級策略
• 規模分級的完整應對 → 規模分級應對表
• Queue 的選型和操作實務 → backend 非同步佇列

四級分級

Tier 1：自用級（< 100 events/sec）

1SDK ──→ Collector (單 binary + SQLite)

Tier 1 的假設是峰值流量不超過 SQLite WAL mode 的寫入能力（每秒數千筆）。自用場景下這個假設幾乎永遠成立。

Tier 2：中型（100-10000 events/sec）

1         ┌─ Collector A ──→ PostgreSQL
2SDK ──→ LB ─┤
3         └─ Collector B ──→ PostgreSQL

Tier 1 → Tier 2 的觸發：SQLite 的 database is locked 頻繁出現，或 dashboard 的聚合查詢需要 PostgreSQL 的能力。

Tier 3：大型（10000-100000 events/sec）

1         ┌─ Collector A ─┐
2SDK ──→ LB ─┤               ├─→ Queue ──→ Worker 群 ──→ PostgreSQL
3         └─ Collector B ─┘

Tier 2 → Tier 3 的觸發：直接寫 PostgreSQL 的背壓頻繁觸發（即使有多個 collector 寫入）。

Tier 4：商業網站級（> 100000 events/sec）

1SDK ──→ CDN/Edge ──→ LB ──→ Collector 群 ──→ Kafka ──→ Worker 群 ──→ 分層 DB
2                                                                      ├─ 即時查詢 DB（ClickHouse / TimescaleDB）
3                                                                      └─ 歸檔 DB（S3 + Athena）

Tier 3 → Tier 4 的觸發：Kafka 單 cluster 的吞吐不夠、或查詢需要跨日誌級的時間序列分析。

多數自架開源工具不需要超過 Tier 2。Tier 3 和 Tier 4 是商業 SaaS 的領域。

規模遷移路徑

每一級的遷移成本遞增。Tier 1 → 2 是 config change 級、Tier 2 → 3 是架構重構級、Tier 3 → 4 是團隊級。選擇起始 tier 時選最低的足夠 tier — 過早引入高 tier 的複雜度是浪費。

下一步路由

• 流量管控的四種機制 → 模組三 流量管控
• 容量預備和壓力測試 → 模組五 容量規劃
• Collector 的可插拔 storage 架構 → monitoring 模組四 規模演進
• Queue 的選型 → backend 非同步佇列

待寫章節

• 突發流量的分類（可預期 vs 不可預期、持續時間和倍率）
• 降級策略（動態取樣、事件優先級、功能降級、聚合前移）
• Queue 緩衝（Kafka / NATS / Redis Streams 做 burst buffer）
• 規模分級應對表（自用 → 中型 → 大型 → 商業網站）

跨分類引用

• ← devops 模組三 流量管控：背壓和 rate limit 是突發應對的基礎元件
• → monitoring 模組四 Collector：Collector 的 ingestion scaling 是本模組的應用場景
• → backend 非同步佇列：Queue 的選型和操作實務
• → devops 模組五 容量規劃：預期突發的容量預備
• → 端到端資料完整性：被自己 SDK DDoS 的三種場景