BT9G LABS / DHT 深度解析 #17

數十億 InfoHash 如何去重？避免重復 Metadata 工作的多層設計

用 exact key、Bloom filter、熱快取和持久化狀態構建多層 InfoHash 去重系統，降低大規模 DHT 採集成本。

BT9G Labs發布於 2026-09-162 分鐘閱讀

BT9G Labs / DHT Deep Dive #17. 去重不是一個 SELECT EXISTS 就結束的問題，而是決定 DHT ingestion 是否能長期擴展的核心子系統。

數十億 InfoHash 如何去重？避免重復 Metadata 工作的多層設計

快速摘要

主題: 數十億 InfoHash 如何去重？避免重復 Metadata 工作的多層設計
核心關鍵詞: InfoHash 去重, Bloom filter, Redis, 大規模 DHT, Metadata scheduler
適合讀者: 後端工程師、協議研究者、搜索工程師以及 BitTorrent 實現者
目標: 用足夠準確的協議與系統視角解釋原理，並能直接支持真實的採集、索引和搜索架構設計。

系統視圖

Raw EventsHot Bloom / CacheExact StoreSchedulerMetadata

Raw Events → Hot Bloom / Cache; Hot Bloom / Cache → Exact Store; Exact Store → Scheduler; Scheduler → Metadata

去重必須是一等公民

熱門 InfoHash 會反復出現在 DHT 流量中。如果每個 observation 都訪問主資料庫並重新創建 Metadata 任務，吞吐量很快就被重復工作耗盡。去重需要從入口開始設計，而不是等資料量達到數億後再補丁式優化。

最常見的分層思路是：進程內短時集合攔截瞬時重復，Bloom filter 過濾絕大多數已知鍵，熱快取保存近期狀態，最終以持久資料庫作為準確 source of truth。

Bloom filter 適合放在前面，不適合作為真相

Bloom filter 的優勢是記憶體效率高、查詢非常快，而且不會出現 false negative；代價是可能產生 false positive。因此它非常適合回答“這個鍵大概率見過嗎”，從而減少昂貴資料庫查詢。

但它不能決定一個 InfoHash 永久不存在或已經完整處理，因為 false positive 可能讓真正的新鍵被誤判。必要時仍要到 exact store 確認。

區分存在狀態和調度狀態

“這個 InfoHash 我見過”與“現在是否需要再次抓 Metadata”是兩個問題。一個已知雜湊可能 Metadata 未成功、內容需要重新驗證，或者新活動讓它值得提高優先級。

因此 durable record 應包含 first_seen、last_seen、metadata_state、retry_state、activity score 等欄位，而不是只有一個 exists 標誌。

為長期增長設計分區

數十億級鍵空間需要考慮資料庫索引大小、寫放大、備份和冷熱資料。可以按雜湊前綴或一致性雜湊分片，使 ownership 穩定並便於橫向擴容。

無論使用 MySQL、LSM 系列存儲還是其他 KV，關鍵都是讓 primary key 和訪問模式貼合高頻 exact lookup，而不要在 ingestion 熱路徑依賴大範圍掃描。

實現示意

CREATE TABLE infohash_state (
  hash VARBINARY(32) NOT NULL,
  hash_type TINYINT NOT NULL,
  first_seen DATETIME NOT NULL,
  last_seen DATETIME NOT NULL,
  seen_count BIGINT NOT NULL,
  metadata_status TINYINT NOT NULL,
  next_retry DATETIME NULL,
  PRIMARY KEY(hash_type, hash)
);

BT9G Labs 工程筆記

對 BT9G 一類索引系統而言，最重要的不是單純追求事件數量，而是把內容身份、網路觀察、採集狀態和搜索文檔拆成清晰的資料層。所有來自 DHT 或 Peer 的欄位都應該保留來源與時間戳，並通過階段化指標區分發現、連接、協商、Metadata 獲取、校驗、入庫和索引等環節。這樣才能在規模擴大後定位真實瓶頸，而不是把所有失敗都歸因於“網路不穩定”。

常見誤區

每個 DHT observation 都查詢主資料庫。
把 Bloom filter 當作絕對準確的 source of truth。
只保存“是否見過”而沒有 Metadata/重試狀態。
等資料達到十億級後才考慮分片與索引大小。

參考資料

下一篇: 為甚麼失敗的 InfoHash 也應該保留：長期重試調度器設計 →

本文用於解釋公開的 BitTorrent 協議與工程實現思路，不代表任何被觀察到的 Swarm 一定可用、有效或被授權傳播。