XML上传失败不能只靠简单for循环重试,因需应对503/429/超时等场景,必须结合退避策略、熔断保护(如Resilience4j或Polly)与上下文隔离;重试时须确保XML内容可重放、字节一致,并配合幂等键。

XML上传失败时为什么不能只靠简单for循环重试
因为网络抖动、服务端限流或临时认证失效导致的 HTTP 503、429 或连接超时,往往需要带退避策略、熔断保护和上下文隔离的重试——裸写 for (int i = 0; i 容易掩盖真实错误、阻塞线程、甚至引发雪崩。
- 无指数退避:连续重试会加剧后端压力,可能让本可恢复的服务彻底不可用
- 无异常过滤:把
400 Bad Request(客户端数据错误)也重试,毫无意义 - 无超时控制:单次请求卡死,整个重试流程挂住
- 无监控钩子:失败多少次、耗时分布、是否触发熔断,全不可见
用 Polly 配置 XML 上传的弹性策略(.NET)
Polly 是 .NET 生态最成熟的弹性库,适合封装 HttpClient 发起的 XML POST 请求。关键是要组合 Retry、CircuitBreaker 和 Timeout 策略,并只对可重试状态码生效。
- 只重试
500、502、503、504和连接异常,跳过4xx(除429) - 使用
ExponentialBackoff:第1次等 1s,第2次约 2s,第3次约 4s - 熔断器设为“连续 5 次失败后开启,持续 30 秒”,避免故障扩散
- 每个重试分支都带
HttpContext或唯一requestId,方便日志追踪原始 XML 内容
var retryPolicy = Policy .Handle() .OrResult (r => r?.StatusCode is StatusCode.ServiceUnavailable or StatusCode.BadGateway or StatusCode.GatewayTimeout or StatusCode.RequestTimeout) .WaitAndRetryAsync( retryCount: 3, sleepDurationProvider: attempt => TimeSpan.FromSeconds(Math.Pow(2, attempt - 1)), onRetry: (outcome, timespan, retryCount, context) => { Log.Warning("XML upload failed (attempt {RetryCount}), retrying in {SleepMs}ms", retryCount, timespan.TotalMilliseconds); }); var circuitBreaker = Policy .Handle
() .CircuitBreakerAsync( exceptionsAllowedBeforeBreaking: 5, durationOfBreak: TimeSpan.FromSeconds(30));
Resilience4j 替代方案(Java/Spring Boot)
如果你用的是 Spring Boot + RestTemplate 或 WebClient,Resilience4j 更轻量、无反射依赖,且天然支持 RetryConfig 的细粒度配置。
- 必须显式调用
Retry.decorateSupplier()包裹实际上传逻辑,否则策略不生效 -
ignoreExceptions列表里要加上IllegalArgumentException——防止 XML 序列化失败被误重试 - 通过
RetryRegistry全局注册策略,便于统一调整所有 XML 接口的重试参数 - 注意
WebClient是响应式,需用Retry.decorateMono()而非decorateSupplier()
RetryConfig config = RetryConfig.custom() .maxAttempts(3) .waitDuration(Duration.ofSeconds(1)) .intervalFunction(IntervalFunction.ofExponentialBackoff()) .retryExceptions(IOException.class, TimeoutException.class) .ignoreExceptions(IllegalArgumentException.class) .failAfterMaxAttempts(true) .build();Retry retry = Retry.of("xml-upload", config); Supplier
> supplier = () -> restTemplate.postForEntity(url, xmlEntity, String.class); ResponseEntity result = retry.executeSupplier(supplier);
重试时 XML 内容怎么保证不丢失或重复提交
这是最容易被忽略的底层细节:HTTP 客户端重试时,如果请求体是流式(如 FileInputStream 或未缓存的 ByteArrayOutputStream),第二次重试会读到空内容——直接导致 400 或空 XML 被接收。
- .NET 中用
new StringContent(xmlString, Encoding.UTF8, "application/xml"),而非直接传Stream - Java 中用
new ByteArrayResource(xmlBytes)或new StringEntity(xmlString, ContentType.APPLICATION_XML) - 若 XML 来自大文件,必须先完整读入内存或生成可重放的
InputStream(如new ByteArrayInputStream(Files.readAllBytes(path))) - 在重试日志中打印
xmlHash.substring(0, 8)而非全文,既可去重又不泄露敏感字段
真正的难点不在加库,而在确认每次重试发出的 XML 字节完全一致,并且服务端有幂等键(如 Idempotency-Key header)配合校验。










