DLQ和有毒消息處理

Dead Letter Queue（DLQ）是隔離的隊列/拓撲消息，用於在給定數量的嘗試後或由於明確的技術/業務原因（非驗證方案，計時器，版本沖突等）而無法由全職用戶處理的消息。有毒消息（poison message）-記錄,其重復處理穩定地以錯誤結束,並威脅到派恩的穩定性。

DLQ的目標是：保留SLO，本地化故障，防止主流鎖定，並確保分析功能和安全重播（redrive）。

1）有毒信息來自何處

模式/合同：不兼容的更改,缺少強制字段,不正確的類型。
業務驗證：重復,不變不變,過期事件。
順序和因果關系：在「Create」之前出現了「Update」,錯過了相關性,超出了順序。
等效性：重復處理會產生副作用。
外部約束：限制限制/時間限制,API不可用。
數據：有效載荷腐敗、編碼不正確、尺寸過大。

2）發送到DLQ的標準

• 超過maxAttempts在消費者/企業家的處理。
• 該錯誤被歸類為有缺陷（非可逆性）：非有效方案，缺乏關鍵資源，業務禁令。
• 截止消息（TTL/expiration）已過期。
• 給定密鑰/tenant的電路斷路器或管理控制策略有效。
• 顯式運算符解決方案（來自主流的手動「eject」）。

3） DLQ拓撲和模式

Per-queue DLQ：每個隊列/拓撲都有自己的DLQ。簡單而透明。
Central DLQ （parking lot）：用於復雜案例的通用「停車」功能,適用於單一分析工具。
DLT （Dead Letter Topic）：對於面向日誌的總線（事件日誌）,是帶有故障原因元數據的單獨拓撲。
Quarantine：帶有硬通道的檢疫緩沖區和用於人工分析的PII消毒。
影子流：將問題消息復制到「陰影」中，以進行安全的虛構實驗。

4） DLQ所要求的元數據

• 故障原因：代碼/錯誤類,stack/trace id。
• 上下文為：「attempt」，「maxAttempts」，「first_seen_ts」，「last_attempt_ts」。
• 相關性：「trace_id」，「span_id」，「tenant_id」，「entity_id」，分期密鑰。
• 原始offset/partition/sequence（用於邏輯總線）或message-id。
• 合同/電路/有效載荷版本。
• Idempotency-key/Request-id（如果有）。
• 路由源：隊列/拓撲名稱,用戶組。

5） DLQ之前的Retrace Policy

• 消費者的簡短回溯：'maxAttempts' 2-5, exponential backoff+jitter, caps on concurrency.
• 合作逆沖：減少競爭,同時增加錯誤.
• 錯誤分類：retryable（'5xx'，taymaut）vs non-retryable（驗證，schema mismatch）。
• 延遲隊列（delay queue）： 5 s → 30 s → 2 m用於臨時故障。
• Per-key隔離：如果「噪音」特定密鑰,請勿阻止整個部件。

6）安全的稀有性（從DLQ重新交付）

Redrive是從DLQ到處理的消息的受控返回。

1.假檢查：僅在修復代碼/配置/方案或恢復外部依賴關系後才重新進行。

2.相似性：處理程序必須具有抗重復性（upsert，推力效應）。

3.重復數據消除：通過「idempotency_key」/「message_id」/「busin_key」。

4.分配和窗口：通過N消息進行毆打，在redrive上進行頻率限制，在時間/批次上進行「窗口」。

5.局部驗證：在紅土之前快速檢查方案（早期非驗證案例的重復）。

6.優先級：Redrive不應取代銷售流量（低優先級操作員/單獨池）。

7.可觀察性：Redrive的單個指標和示蹤劑；結果報告（成功/重復DLQ/損失）。

7）交付語義和順序

On-Least-once是最常見的模式：必須具有等效性和重復數據消除功能。
最多-可以禁用DLQ；損失風險。僅在有效損失時使用。
Exactly-once（有效）：通過業務存儲中的事務和重復數據消除實現；昂貴且具體。
順序：DLQ通常會中斷特定密鑰/批次的順序。如果順序是關鍵的，則按鍵依次重復。

8）計劃，合同和驗證

Schema registry/合同：清晰的認證，具有反向/前向兼容性的演變。
入口驗證：在艱難的步伐之前，通過JSON Schema/Protobuf/Avro進行廉價檢查。
不兼容性策略：在「斷開」字段中,立即在DLQ中使用代碼「SCHEMA_INCOMPATIBLE」。
Redaction PII：在DLQ中僅存儲必需品；敏感字段掩蓋。

9）相似性和重復數據消除

Idempotency-key：從「商業意義」（tenant+entity+operation+ts-bucket）在生產商上形成。
Dedup雜誌：使用TTL存儲最後「N」鑰匙；記住操作的「效果」。
Upsert/merge：不受限制地避免「僅插入」。
副作用：對於外部呼叫-在呼叫之前記錄並檢查「重播」。

10）可觀察性和SLO

• DLQ比率（msg/s），消息比例，DLQ中平均/中等「年齡」。
• Redrive成功（％），重復DLQ份額。
• 原因分類：計劃,驗證,定時,dependency,未知。
• p95/p99在redrive中處理主流vs的潛伏期。
• DLQ大小,溢出風險。

• 強制性標簽：'message_id'、'entity_id'、'tenant_id'、'attempt'、'reason'、'redrive_batch_id'。
• 「DLQ分支」跟蹤：從源頭到重新成功。

SLO:

在T分鐘內成功處理消息的比例≥ X%。
DLQ案例的調查和修復時間≤ Y小時。
DLQ ≤ Z時鐘中消息的最大「年齡」（帶有變量）。

11）安全性和合規性

根據最小特權原則進行訪問：redrive僅限於操作員/花花公子。
審計：誰以及何時觸發重新分區/刪除/編輯元數據。
消毒：轉移到中央DLQ時,刪除額外的PII/秘密。
Retention： DLQ的單獨保留時間和刪除策略。

12）多重性

「tenant_id/plan」標簽：區分限制、重做優先級、報告。
Per Tenant DLQ或分期付款：以便「嘈雜」的客戶端不會得分共享的DLQ。
計費/配額：考慮使用DLQ的範圍和redrive的成本。

13）配置模板（示例）

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14）操作花花公子（runbooks）

1.DLQ的異常增長：啟用脫粒程序用戶,分析頂級原因,檢查發布/模式。
2.Schema mismatch：回滾/提交電路,遷移適配器,redrive檢查後。
3.外部依存關系不可用：中繼暫停、啟用延遲隊列、恢復後重新啟動。
4.Redrive後重復DLQ：啟用「影子」處理程序/模擬器，測試冪等，縮小擊球範圍。
5.DLQ溢出：疏散到存檔存儲,啟用選擇性的按鍵/原因重新分區。

15）測試和混亂

錯誤註入：計劃破裂，驗證，計時器，1-na-N「粘性」錯誤。
質量稀有性：檢查劑量和對裂紋的影響。
序列的順序：正確的密鑰處理。
有效載荷腐敗：驗證和安全故障。
從紅土制造者跌倒中恢復：擊球操作的冪等性。

16）典型錯誤

DLQ中缺少元數據→無法聚類原因並安全地重新分區。
無限制的質量稀土→生產的重復降解。
沒有等效性/重復數據消除→雙倍和副作用。
將PII混入中央DLQ而無需消毒。
缺乏計劃/合同→消息演變中的「驚喜」。
單個共享DLQ，不分期付款/密鑰。
無限重置而不是早期的DLQ，以產生非可重置錯誤。

17）快速食譜

常規業務線程：3-4次嘗試,指數回波與抖動,早期錯誤分類,DLQ與完整的元數據。
關鍵事件（付款）：嚴格的等效性,短時間,最少嘗試,快速DLQ和手動解析。
小說後大規模稀有：小擊球（100-500）,極限率,單獨的槍手池,在速度提高之前監測成功>95%。
Tenant：Redrive上的tenant per限制，DLQ頂級客戶生成器報告。

結論

DLQ不是「垃圾箱」，而是受控的可靠性回路。清晰的命中規則、豐富的元數據、相容性和重復數據消除、安全的劑量稀有度、電路紀律和可觀察性將有毒信息從SLO威脅轉變為可管理的工程過程-可理解的花花公子、預測的成本以及對用戶的影響最小。