面向唯一字符串计数的高并发并行集合选型与Rust服务性能优化

核心问题定位 #

你当前实现的性能瓶颈根本不在并发集合的锁竞争上，之前尝试Crossbeam跳表没有获得性能提升，本质是因为换什么并发集合都绕不开两个占了90%耗时的冗余步骤：

• 业务明确不需要留存具体词值，但你的实现为每个分词结果都分配独立的String堆内存，伴随而来的内存申请、字符拷贝、字符串析构开销，远大于集合本身的并发访问开销
• 不管是DashSet还是跳表，在你当前的负载下，锁竞争的实际占比其实很低，真正拖慢速度的是每分词一个词就要做一次堆内存分配的操作。

具体优化思路 #

1. 彻底取消字符串存储，用哈希值替代原词做去重 #

这是性能提升最明显的改动，完全匹配你“不需要留存具体词值”的业务要求：

• 把原有的DashSet<String>直接替换为存储128位哈希键的DashSet<u128>，128位双哈希的冲突概率低到可以忽略，完全满足精确去重的需求
• 分词后不需要构造String，直接对当前的&str引用计算两个独立的低开销快速哈希值，拼接成128位的键直接插入集合
• 改动后的核心分词循环代码示例：

  // 复用哈希器实例，避免重复创建的额外开销
  let mut hasher1 = ahash::AHasher::default();
  let mut hasher2 = fxhash::FxHasher::default();
  for word in input.split_whitespace() {
      word.hash(&mut hasher1);
      word.hash(&mut hasher2);
      let key = (hasher1.finish() as u128) << 64 | hasher2.finish() as u128;
      db.insert(key);
      // 重置哈希器状态供下一个词使用
      hasher1 = ahash::AHasher::default();
      hasher2 = fxhash::FxHasher::default();
  }
  

  这一步改动就能消除90%以上的字符串分配开销，性能基本可以追到Java实现的水平。

2. 业务精度允许的话，直接用HyperLogLog替换哈希集合 #

如果你的业务对唯一词计数的误差要求在1%以内（绝大多数统计场景完全可接受），直接用并发友好的HyperLogLog（HLL）结构替换现有DashSet：

• HLL天生就是为“统计唯一元素总数、不存储原元素”的场景设计的，单实例仅需数KB到数十KB内存，插入操作仅需对输入词计算哈希、更新对应寄存器，没有任何堆内存拷贝或者高锁竞争的开销
• 重置计数器的操作仅需清空寄存器值，速度远快于清空哈希集合
• 整体性能会比精确存储哈希值的方案再提升数倍。

3. 消除全量字符串解压的冗余开销 #

当前实现每次请求都把整个gzip解压后的内容读入一个新的大String再分词，可以进一步优化：

• 用流式分词替代全量读入：边解压、边从字节流中切分空白符、边处理分词结果，不需要把整个解压后的文本存成大字符串，减少大内存块的分配和拷贝
• 把解压器、分词用的临时缓冲区做成线程本地变量复用，避免每次请求都重新分配内存。

4. 降低全局集合的锁竞争 #

• 给本地处理线程加一层小型去重缓冲：把单次请求内的分词结果先存在本地的轻量集合里做临时去重，请求处理完成后再把去重后的哈希值批量插入全局集合，避免重复出现的词反复抢占全局集合的访问锁
• 根据业务预估的最大唯一词规模，提前设置全局集合的初始容量，避免运行过程中集合自动扩容重哈希带来的全表锁开销。

内容的提问来源于stack exchange，提问作者Jan Veselý