使用BigQuery流式insertAll插入38000条记录时遇超时、连接重置如何解决

补全重试配置的全链路参数 #

仅设置90分钟总超时的配置，无法覆盖单请求超时、连接状态管控的场景，是触发Read timed out、Connection reset的核心原因，需要按如下方式调整RetrySettings：

RetrySettings retrySetting = RetrySettings.newBuilder()
  // 单请求等待响应的读超时设为60s，匹配批量插入的常规响应时长
  .setInitialRpcTimeout(Duration.ofSeconds(60))
  // 单请求连接建立超时设为20s，避免TCP建连阶段长时间卡死
  .setRpcTimeout(Duration.ofSeconds(20))
  // 初始重试间隔1s，按2倍系数递增，避免触发服务端限流
  .setInitialRetryDelay(Duration.ofSeconds(1))
  .setRetryDelayMultiplier(2.0)
  .setMaxRetryDelay(Duration.ofSeconds(10))
  // 仅对临时类异常触发重试，不对永久类报错（如表不存在、权限不足）做无意义重试
  .setRetryableCodes(
    StatusCode.Code.DEADLINE_EXCEEDED,
    StatusCode.Code.UNAVAILABLE,
    StatusCode.Code.RESOURCE_EXHAUSTED
  )
  // 保留原有90分钟总超时的合理设置
  .setTotalTimeout(Duration.ofMinutes(90))
  .build();

• Connection reset报错的本质是TCP连接被中间网络节点（防火墙、负载均衡）静默断开，并非总写入时长不足。需要在构建BigQuery客户端时开启TCP保活，将空闲连接的存活阈值设为5分钟，低于常见网络节点10分钟的空闲断连规则，提前释放、重建连接，避免使用已经失效的连接发起请求。

优化批量插入的分片策略 #

• 不要将38000条记录一次性全量提交：BigQuery单次insertAll请求的推荐规模为单批1000-5000条记录，单批请求体大小不超过10MB。一次性提交全量记录很容易因为请求体过大、传输时间过长触发网络层超时、连接重置。
• 按分片逐批提交：将38000条记录拆分为8个左右的分片，每批不超过5000条，逐批发起请求。单批的失败仅针对当前分片重试，不需要全量回退，大幅降低单次请求的异常影响范围。
• 为每条插入记录设置唯一的insertId：开启重试时，BigQuery服务端会根据该ID自动去重，不会出现重复写入的问题。

增加流程层的容错兜底机制 #

• 单独捕获每批插入返回的InsertErrors：不要因为单条记录的格式错误、字段不匹配等问题导致整批插入全部失败，过滤掉无效记录后，对剩余有效记录重试提交。
• 控制单分片的重试次数：单分片最多重试3-5次，超过次数的分片写入本地临时队列，等所有正常分片提交完成后，再统一对临时队列里的分片做重试，避免单个异常分片长时间阻塞整个写入流程。
• 正式插入前做一次链路探活：先调用一次目标表的元数据查询接口，确认网络链路连通后再开始批量插入，避免冷启动阶段使用失效连接发起请求。

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