背景：分區順序不足以支撐工作階段語意
InfoQ 文章《Building a Session-Ordered Kafka Pipeline in Go》由 Joshua Oluikpe 撰寫，描述一個服務企業客戶的即時對話式 AI 平台。其核心訊息層以 Go 實作，訊息流經 ingest、自然語言理解、大型語言模型推論與 delivery 四個階段。這類系統的順序帶有語意：使用者先說「幫我訂飛倫敦的航班」，再說「改成巴黎」，若第二句先被處理，系統就會依錯誤上下文回應。當數千個工作階段同時流動，即使罕見的順序破壞也會累積成產品問題。
Kafka 只保證同一分區內的順序，但一個分區通常承載多個工作階段交錯的流量。若要做到工作階段內嚴格有序，同時讓不同工作階段平行處理，應用層必須自行路由。把每個工作階段對應到一個分區看似直接，卻不可行：數千個並行工作階段會產生過多分區，超出營運限制並拖慢 broker；每個分區單執行緒也不適合，因為分區內仍是多個工作階段的交錯流量。
核心架構：兩層工作者與工作階段親和
系統改採兩層工作者。第一層是 SessionWorkers 派送層，由輕量派送工作者從 Kafka 接收紀錄，依 session ID 路由。一致雜湊確保同一工作階段的訊息永遠送到同一個工作者，不同工作階段則可分散平行處理。第二層是每個工作階段專屬的 goroutine，按抵達順序一次處理一則訊息。這些 goroutine 隨需求建立，閒置後移除，資源使用量與作用中工作階段數成比例。工作階段內序列化由結構保證，跨工作階段平行度在設計上不受限。
生產者端同樣需要工作階段親和。非同步發送使用相同一致雜湊策略，讓同一工作階段訊息進入同一個生產者工作者並以 FIFO 順序送出。發送失敗會升級到 broker 的 DLQ，關閉時先排空並沖刷待寫入資料，再關閉 Kafka 客戶端。
就地重試與連續浮水印
重試若用獨立 goroutine 並把後續訊息暫存在記憶體，會讓狀態機複雜且帶來無界記憶體風險。這個系統改為在 session goroutine 內就地重試。每則訊息先嘗試處理，成功就標記完成並立即處理下一則。若屬可重試的暫時性錯誤，例如下游服務逾時，goroutine 以指數退避加抖動等待後重試同一則訊息。等待期間 goroutine 被阻塞，同工作階段後續訊息只能排在後面，無法超車。若錯誤不可恢復，例如訊息資料無效，則不重試，直接送往死信佇列。錯誤分類只有兩層：暫時性錯誤重試，毒藥訊息或不可恢復錯誤直接進 DLQ。
多個工作階段 goroutine 會亂序完成，因此不能天真提交最新完成位移。若位移 104 比 102 先完成，直接提交 104 會讓崩潰後復原跳過 102。系統以每分區位移追蹤元件維護連續浮水印，記錄 InFlight 與 Completed，固定提交週期只推進到最高連續完成位移。處理中的缺口會阻擋浮水印前進。崩潰後從安全位移重播，部分訊息可能重複處理；系統攜帶穩定事件 ID 去重，但外部副作用仍取決於下游冪等保證，因此重播不等於 exactly-once。少數交接中斷可能在浮水印留下永久缺口，協調器會追蹤未解決缺口，超過處理逾時後強制略過，避免分區永久停滯。這是可用性優先的最後手段，該事件應視為營運失敗，而非正常成功送達。
營運強化：再平衡、背壓與卡住位移
要在真實故障下維持順序，還需營運防護。再平衡時，消費者先把分區標記為 revoking，停止路由新紀錄，等待進行中的工作階段工作完成，每 50 毫秒檢查一次並遵守 broker 再平衡逾時。完成後提交最終連續浮水印、清除分區狀態，所有權才移交另一消費者。
背壓方面，工作者飽和時不丟訊息也不崩潰，而是暫停抓取。訊息路由使用非阻塞通道傳送；若派送通道已滿，就暫停該分區，由監控 goroutine 每秒輪詢容量，低於恢復門檻後再恢復。已拉入的目前批次會依分區緩衝並保持 in-flight 標記，避免遺失或讓浮水印提前推進；必須等緩衝清空且工作者有足夠容量才恢復抓取，以免新紀錄超車舊緩衝訊息。這提高工作階段隔離，但未消除分區層級耦合：暫停一個分區仍可能暫時延遲無關工作階段。
卡住位移偵測也很重要。若某個 session goroutine 因下游呼叫不終止或死鎖永久阻塞，該分區提交浮水印會凍結，後續位移全部無法提交。早期偵測器把持續非空的 in-flight 集合視為卡住，在穩定流量下會誤報；現行做法逐一追蹤每個位移，只有處理時間超過設定逾時才標記。卡住位移可被強制完成並記錄到 DLQ，讓分區繼續前進。生產可觀測性還需跨非同步 Kafka 邊界的追蹤連結，以及分區暫停期間仍能獨立回報延遲，讓自動擴縮取得有用訊號。
驗證、效能與限制
驗證分兩階段。合成基準測試在 AWS EC2 c5.2xlarge（8 vCPU、16GB RAM）、三 broker Kafka 叢集、每主題 10 分區、複寫因子 3 的環境執行，每個消費者實例處理 4 個分區，共 3 個消費者實例。200 毫秒目標只涵蓋 ingest、路由、交接與 delivery 的訊息開銷，不包含變動的 LLM 推論時間。合成測試以模擬下游處理，並對 10% 訊息注入暫時性錯誤，結果在 50,000 則訊息、10 個並行工作階段下，原始吞吐量 14,027 msg/s，端到端延遲 p50 為 11.7 毫秒、p95 為 115 毫秒、p99 為 185 毫秒，順序破壞 0 次，工作階段親和 100%。
第二階段以 WebSocket 驅動對已部署管線做生產規模壓力測試，1,000 個並行工作階段，目標 50,000 msg/s。實際送達率 48,805 msg/s，共送出 11,959,510 則，發送錯誤 0，端到端延遲 p50 為 446.8 毫秒、p95 為 2,633.9 毫秒、p99 為 2,843.1 毫秒。尾端延遲超過 200 毫秒預算，原因是 WebSocket 路徑超過 API Gateway 訊息速率配額，而非排序機制造成。該高速率測試未獨立驗證每工作階段順序；明確順序驗證在合成基準完成。正式上線後，系統處理超過 4,000 萬則訊息，在真實流量、變動 LLM 推論時間、網路抖動與負載尖峰下，未觀察到順序破壞。此為營運觀察與監控結果，不是逐訊息序列檢查。DLQ 僅 460 則，約 0.002%。驗證方法是在生產者為每則訊息指定工作階段內單調遞增序號，消費者測試框架記錄每工作階段處理順序，並檢查同一工作階段是否只由一個工作者處理。生產環境以消費者延遲、處理時間、重試、DLQ 數量、待處理緩衝深度與背壓事件作為訊號，但這些不是直接序列檢查。
團隊也曾評估 Redis Streams。它提供消費者群組、訊息確認與合理順序保證，對較簡單工作負載可能合適；但在此案例仍需要應用層協調工作階段親和與復原記帳。Kafka 的分區與位移模型，加上應用層工作階段感知路由，對嚴格工作階段順序、重播與跨工作階段高平行度更合適。
整體而言，嚴格工作階段順序不能只靠 Kafka 分區保證。一致雜湊提供工作階段親和，每工作階段 goroutine 序列化處理與重試，連續浮水印讓並行處理可復原，再平衡排空保護分區交接。背壓、卡住工作與優雅關閉等營運強化，把架構保證變成能承受真實條件的系統。這些模式適用於任何訊息順序帶有語意的工作負載，包括對話系統、工作流程引擎與交易處理。限制在於，重播安全仍依賴下游冪等，強制略過缺口會犧牲完整性，而分區暫停仍可能造成跨工作階段延遲耦合。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。