调用频繁超时远程API的大CSV处理Spring Boot微服务重构方案咨询

场景约束前置对齐 #

• 远程API无批量处理能力、逻辑完全不可修改
• 每个待处理业务对象仅允许发起单次合规GET请求，不能随意重复发送同参数请求
• 现有Resilience4j防护效果差的核心原因，是流量打向脆弱API的节奏没有做平滑控制，不是熔断/降级逻辑本身的问题

缓存优先的效率优化路径 #

• 全量预扫做缓存去重：处理CSV前先提取所有待请求的唯一标识，和已持久化的请求结果缓存做全量比对，已经拉取成功的对象直接跳过远程调用，不再发起重复请求。缓存可直接存为S3上的分片小文件，避免微服务重启丢失已有结果
• 平滑限流替代高并发打流：取消原有的无上限并发线程池，替换为令牌桶整形的固定速率发流器，严格按照远程API实际可稳定承载的QPS匀速发请求，从源头降低API高负载下的超时概率，比触发熔断后再失败的模式整体吞吐量更高
• 超时阈值校准：把原有的硬编码超时时间，调整为远程API P99响应时长的1.3倍，避免因超时设置过短，把正常返回的请求误判为超时，徒增无效请求量

状态留存与重试机制实现 #

• 独立状态台账分片存储：为每一行CSV的处理过程维护独立状态记录，字段至少包含行号、原始CSV内容、请求参数、处理状态（待处理/处理中/成功/失败）、失败原因、已重试次数。台账按每千行做分片，以JSON格式存在S3上，避免单文件过大
• 断点续跑能力：微服务每次启动时优先扫描S3上的状态台账，跳过所有标记为成功的条目，仅从处于待处理、失败状态的条目继续执行，不需要重新解析全量CSV从头跑
• 合规重试队列：将失败条目划入独立的重试任务队列，按指数退避策略延后重试，不占用实时批次的处理资源。严格遵守单次GET请求的约束：仅当失败原因是明确的客户端连接失败、API返回4xx/5xx类无处理结果的响应时，才允许重试；对超时类模糊异常，必须先查询缓存确认是否已经拿到过该对象的返回，避免重复发起请求触发API风控

现有Resilience4j的配置调整 #

• 将原有的快速失败策略调整为基于阻塞队列的限流策略，把实际打到API的并发量稳定控制在API可承载的范围内，不要靠扩大线程池数量提升处理速度
• 关闭Resilience4j对超时类异常的隐式自动重试，所有重试动作交状态台账驱动，避免隐式重试违反单次请求的约束

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