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 一定可用、有效或被授权传播。