背壓 vs Rate Limit

背壓和 rate limit 都是流量控制，但觸發邏輯不同：

背壓在系統承載達到上限時才觸發，rate limit 在到達預設上限時就觸發（即使系統還有餘裕）。兩者互補：rate limit 防止單一來源打爆系統，背壓防止所有來源加起來打爆系統。

實作模式

有限 buffer + 回壓訊號

最常見的背壓實作是在處理管線中加一個有限容量的 buffer。Buffer 滿了代表下游處理不完，這時對新請求回傳「忙碌」訊號。

在 Go 的 HTTP server 中，buffer 可以是一個有限容量的 channel：

 1var ingestCh = make(chan Event, 10000) // 有限 buffer
 2
 3func handleIngest(w http.ResponseWriter, r *http.Request) {
 4    event := parseEvent(r)
 5    select {
 6    case ingestCh <- event:
 7        w.WriteHeader(http.StatusAccepted) // 202
 8    default:
 9        w.Header().Set("Retry-After", "5")
10        w.WriteHeader(http.StatusTooManyRequests) // 429
11    }
12}

Buffer 容量的選擇取決於下游的處理速度和可接受的記憶體用量。每個 event 約 1KB 時，10000 容量的 buffer 佔 ~10MB — 對多數服務來說可以接受。

HTTP 429 + Retry-After

HTTP 429 Too Many Requests 是標準的回壓訊號。Retry-After header 告訴 client 多少秒後重試。

Retry-After 的值可以是固定的（如 5 秒），也可以根據 buffer 的填充程度動態計算 — buffer 越滿、Retry-After 越長。

TCP 層的背壓

TCP 協議本身有背壓機制 — 接收端的 receive window 縮小時，發送端自動減速。但 HTTP 層的背壓比 TCP 層更精確，因為 HTTP 可以回傳語意化的狀態碼和 header，client 可以根據語意做出更智慧的回應（如優先重試 error 事件、放棄 event 事件）。

監控系統的應用

監控系統的 collector 是背壓的典型場景：多個 SDK 同時 flush 事件到 collector，collector 的寫入速度（SQLite / PostgreSQL）是瓶頸。

背壓鏈路：SDK flush → collector HTTP endpoint → 寫入 channel（有限容量）→ 寫入 goroutine → storage。Channel 滿時回 429，SDK 的離線 buffer 機制接手 — 事件暫存本地，等 collector 恢復後補發。

這個設計讓 collector 在高峰時不崩潰（有限 buffer 控制記憶體）、SDK 端不丟事件（離線 buffer 暫存）。代價是事件的到達有延遲（Retry-After 時間 + 補發時間）。

下一步路由

• 主動的流量限制 → Rate Limiting
• 依賴服務失敗時的防護 → 熔斷器
• 突發流量時的組合策略 → 模組七 突發流量

兩個粒度

Per-client（每來源限速）

限制每個 client（by API key / IP / SDK instance）的請求速率。防止單一來源打爆系統。

自用場景下 per-client 限速的價值不高（只有自己的 SDK），但開源工具被多人部署後，per-client 限速防止某個失控的 SDK 影響其他來源。

Global（全局限速）

限制系統的總吞吐量。不管多少個 client，collector 每秒最多處理 N 個事件。

Global 限速是系統保護的最後一道線 — 即使每個 client 都在限速內，所有 client 加起來可能超過系統承載。Global 限速確保總量不超過系統能力。

演算法

Token Bucket

桶裡有固定數量的 token，每個請求消耗一個 token，token 按固定速率補充。桶空了就拒絕。

特點：允許短暫 burst（桶滿時一次消耗多個 token），但長期平均不超過補充速率。適合「允許偶爾的高峰但長期平均要在限制內」的場景。

Sliding Window

在固定的時間窗口（如 1 分鐘）內計數請求。超過上限就拒絕。窗口結束時計數重設。

特點：嚴格的速率限制（窗口內不會超過 N 個），但窗口邊界有突增風險（上一個窗口末尾 + 下一個窗口開頭各 N 個 = 瞬間 2N）。滑動窗口（sliding window log / counter）解決邊界問題但記憶體較高。

選擇

自架監控系統推薦 token bucket — 允許 SDK 的 flush burst（一次送 100 個事件是正常行為），但限制長期平均速率。

HTTP 429 + Retry-After

限速觸發時回 HTTP 429 Too Many Requests，帶 Retry-After header 和 rate limit 相關 header：

1HTTP/1.1 429 Too Many Requests
2Retry-After: 5
3X-RateLimit-Limit: 1000
4X-RateLimit-Remaining: 0
5X-RateLimit-Reset: 1719302400

SDK 收到 429 後觸發離線 buffer 暫存事件，Retry-After 秒後重試。

優先級豁免

某些請求不應被限速：

優先級的判斷依據是「這個事件丟了的代價」。Error 事件丟了影響 debug 能力，event 事件丟了影響行為分析精度 — 前者的代價更高。

下一步路由

• 被動的流量控制 → 背壓機制
• 依賴失敗時的快速失敗 → 熔斷器
• 不同工作負載的資源隔離 → Bulkhead 隔離
• Backend 的 rate limit 實作（middleware / Redis / 配額設計）→ Rate Limit 實作

三狀態模型

Closed（正常）

所有呼叫正常通過。熔斷器記錄成功和失敗的計數。

Open（熔斷）

當失敗率或連續失敗次數超過閾值時，熔斷器進入 open 狀態。此後所有呼叫立即回傳錯誤，不實際呼叫外部依賴。

Open 狀態持續固定時間（如 30 秒），時間到後進入 half-open。

Half-open（探測）

允許少量呼叫（如 1 個）實際通過到外部依賴。如果成功 → 回到 closed；如果失敗 → 回到 open（重設計時器）。

Half-open 的目的是自動探測依賴是否恢復，不需要人工介入。

熔斷判斷條件

「失敗」的定義需要明確：HTTP 5xx 是失敗、4xx 通常不是（client 的問題）、timeout 是失敗、connection refused 是失敗。

熔斷時的 fallback

熔斷觸發後，呼叫端收到的是「快速失敗」而非逾時。呼叫端需要有 fallback 策略：

沒有 fallback 的依賴被熔斷 = 對應功能完全不可用。熔斷器保護的是「不讓不可用的功能拖垮整個服務」。

監控系統的應用

Collector 的 rule engine 在規則命中時可能呼叫外部服務（Slack webhook、HTTP POST 到 alert endpoint）。如果外部服務掛了，每個命中的規則都會等待逾時 — 大量規則命中時 goroutine 積壓。

熔斷器包在 rule engine 的「執行外部動作」環節：連續 5 次外部呼叫失敗 → 熔斷 → 後續規則命中不再嘗試外部呼叫、改寫本地 log → 30 秒後探測一次 → 外部服務恢復 → 恢復正常呼叫。

下一步路由

• 被動的流量控制 → 背壓機制
• 主動的速率限制 → Rate Limiting
• 不同工作負載的資源隔離 → Bulkhead 隔離

隔離什麼

服務中的共享資源是 bulkhead 的隔離對象：

實作模式

獨立 Goroutine Pool

Go 中用有限容量的 channel 模擬 goroutine pool：

 1var (
 2    ingestPool = make(chan struct{}, 100)  // ingestion 最多 100 goroutine
 3    queryPool  = make(chan struct{}, 20)   // query 最多 20 goroutine
 4    rulePool   = make(chan struct{}, 10)   // rule engine 最多 10 goroutine
 5)
 6
 7func handleIngest(w http.ResponseWriter, r *http.Request) {
 8    select {
 9    case ingestPool <- struct{}{}:
10        defer func() { <-ingestPool }()
11        processIngest(r)
12    default:
13        http.Error(w, "ingestion overloaded", http.StatusServiceUnavailable)
14    }
15}

Ingestion 的 100 個 goroutine 全部被佔用時，新的 ingestion 請求被拒絕（503），但 query 和 rule engine 的 goroutine 不受影響。

獨立 Connection Pool

資料庫連線池按工作類型分開：

1// driver name 依實際使用的 driver 而定（modernc.org/sqlite 用 "sqlite"、mattn/go-sqlite3 用 "sqlite3"）
2ingestDB := sql.Open("sqlite", "events.db")
3ingestDB.SetMaxOpenConns(10) // ingestion 專用
4
5queryDB := sql.Open("sqlite", "events.db")
6queryDB.SetMaxOpenConns(5)   // query 專用

SQLite 的特殊情況：SQLite 是檔案級鎖定，多個連線池打開同一個檔案時仍共享 write lock。連線池隔離在 SQLite 上主要隔離的是 Go 層的 goroutine 等待，不是 DB 層的鎖定。PostgreSQL 的連線池隔離則是真正的資源隔離。

容量分配

Bulkhead 的每個隔艙分配多少資源是設計決策。分配依據是「這個工作負載的優先順序和預期併發量」：

分配比例不需要精確 — 重點是每個隔艙有獨立的上限，而非共享一個無差別的總上限。

監控系統的應用

Collector 同時承載 ingestion（接收事件）、query（dashboard 查詢）和 rule engine（規則評估）三種工作。不隔離時，一個複雜的 dashboard 查詢（full table scan）可能佔住所有資料庫連線，讓 ingestion 的寫入也排隊等待。

Bulkhead 設計讓 ingestion 和 query 各自的過載互不影響：

• Ingestion 的 goroutine pool 滿了 → SDK 收到 429 → 離線 buffer 接手
• Query 的 goroutine pool 滿了 → dashboard 暫時顯示 loading → 不影響 ingestion
• Rule engine 的 goroutine pool 滿了 → 規則評估延遲 → 不影響事件接收和查詢

下一步路由

• 背壓的流量控制 → 背壓機制
• 依賴失敗的快速失敗 → 熔斷器
• 突發流量時的綜合策略 → 模組七 突發流量