使用唯一索引时GridFS生成孤立块的问题排查求助

结论 #

这个行为是GridFS当前实现的设计局限，而非官方定义的bug——因为GridFS的默认存储流程就是先写入所有文件块，再写入关联的元数据文档，唯一索引的冲突校验只在写入元数据这一步触发，导致校验失败时已经产生了孤立块。这种设计确实会造成带宽和存储浪费，是可以提前规避的。

原因说明 #

GridFS的核心逻辑是拆分大文件为多个chunks存储，最后通过files集合中的文档来关联这些块。整个流程是：

1. 拆分文件并写入所有chunks文档
2. 写入包含元数据的files文档，此时才会触发唯一索引的约束检查
   当元数据字段重复触发E11000错误时，chunks已经全部写入数据库，自然留下了孤立数据。

规避方案 #

• 提前校验元数据唯一性
  在上传文件前，先查询files集合确认要使用的元数据字段是否已存在，避免无效上传：

  // 假设唯一索引字段为"uniqueMetadataKey"
  Query checkDuplicate = Query.query(Criteria.where("uniqueMetadataKey").is(targetValue));
  if (gridFsTemplate.exists(checkDuplicate)) {
      throw new RuntimeException("该元数据值已存在，无需重复上传");
  }
  // 执行上传操作
  gridFsTemplate.store(fileInputStream, fileName, contentType, metadata);
  

• 利用MongoDB事务回滚（4.0+版本支持）
  将chunks写入和files文档写入放在同一个事务中，一旦元数据写入失败，事务回滚会自动删除已写入的块：

  try (ClientSession session = mongoTemplate.getMongoClient().startSession()) {
      session.startTransaction();
      try {
          GridFsTemplate txGridFs = new GridFsTemplate(mongoTemplate.getMongoDbFactory(), mongoTemplate.getConverter());
          txGridFs.store(fileInputStream, fileName, contentType, metadata);
          session.commitTransaction();
      } catch (MongoWriteException e) {
          session.abortTransaction();
          throw e;
      }
  }
  

• 定期清理孤立块
  如果无法提前拦截，可以定时清理没有对应files文档的chunks：

  // 替换为你的GridFS桶名称
  db.myBucket.chunks.deleteMany({
      files_id: { $nin: db.myBucket.files.distinct("_id") }
  })
  

  可以通过MongoDB定时任务或后台调度执行这个清理操作。

内容的提问来源于stack exchange，提问作者hsb