Bash脚本统计AWS S3文件记录数：大数据集计数异常排查

小数据集正常、大数据集计数不准，核心问题基本出在多线程并发操作的资源竞争、AWS请求限流或脚本逻辑的同步缺陷上，以下是具体排查方向和修复方案：

1. 共享变量的并发写入冲突 #

如果脚本用全局变量（比如total=0）直接累加各线程的行数，大数据量下多个线程同时读写该变量会导致数值覆盖，最终计数偏小。

• 排查：检查脚本中是否存在total=$((total + line_count))这类直接操作全局变量的逻辑
• 修复：放弃全局变量累加，改用唯一临时文件记录每个线程的结果，最后统一求和：

  # 每个线程内的逻辑：将行数写入唯一临时文件
  tmp_file="/tmp/line_count_$$_$RANDOM.txt"
  aws s3 cp "s3://$bucket/$object" - | wc -l > "$tmp_file"
  
  # 所有线程启动后等待完成，再求和
  wait
  total=$(cat /tmp/line_count_*.txt | awk '{sum+=$1} END {print sum}')
  rm -f /tmp/line_count_*.txt
  

2. AWS请求被限流 #

同时发起数千个S3下载请求时，AWS会触发请求限流（Throttling），导致部分文件下载失败、未被统计。

• 排查：给每个线程添加错误日志，检查下载失败情况：

  aws s3 cp "s3://$bucket/$object" - | wc -l > "$tmp_file"
  if [ $? -ne 0 ]; then
      echo "下载失败：$object" >> /tmp/s3_download_errors.log
  fi
  

• 修复：
  • 降低并发数（比如把脚本第三个参数从10调至5，避免一次性发起过多请求）
  • 给AWS CLI添加重试参数：aws s3 cp --retries 3
  • 先通过aws s3api list-objects-v2获取完整文件列表，再分批处理，避免瞬间请求过载

3. 临时文件命名冲突 #

如果多个线程共用同一个临时文件名，会导致内容被覆盖，统计结果混乱。

• 排查：检查脚本中临时文件的命名规则，是否存在多个线程写入同一文件的情况
• 修复：用线程PID+随机数生成唯一文件名，比如/tmp/line_count_$$_$RANDOM.txt

4. 未等待所有线程完成就求和 #

如果脚本启动后台线程后，没有用wait命令等待所有线程结束就开始计算总和，会导致部分线程的统计结果未被纳入。

• 排查：检查脚本末尾是否有wait命令
• 修复：在所有线程启动循环结束后，添加wait命令，确保所有统计任务完成后再求和：

  # 启动所有线程的循环
  for object in $(aws s3 ls s3://$bucket/$prefix --recursive | awk '{print $4}'); do
      (
          # 统计逻辑
      ) &
  done
  wait  # 等待所有后台线程执行完毕
  # 执行求和操作
  

5. 管道数据流异常 #

高并发下，aws s3 cp ... | wc -l的管道可能出现缓冲区截断，导致wc统计行数不准。

• 排查：改用本地临时文件中转后统计，对比结果：

  local_tmp="/tmp/s3_tmp_$$_$RANDOM"
  aws s3 cp "s3://$bucket/$object" "$local_tmp"
  line_count=$(wc -l < "$local_tmp")
  echo "$line_count" > "$tmp_file"
  rm "$local_tmp"
  

• 修复：如果本地中转后计数正常，就改用这种方式替代管道统计。

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