本文介绍一种不依赖 redis 的轻量级方案，利用 spring boot 原生能力（如 resttemplate + spring retry）实现“等待数字签名就绪、超时后降级发送”的业务逻辑，兼顾可靠性、可维护性与开发效率。
本文介绍一种不依赖 redis 的轻量级方案，利用 spring boot 原生能力（如 resttemplate + spring retry）实现“等待数字签名就绪、超时后降级发送”的业务逻辑，兼顾可靠性、可维护性与开发效率。
在实际支付类系统中，向商户发送交易回执时需附带数字签名——而该签名由独立签名服务异步生成，可能短暂不可用（返回 404 Not Found）。此时，核心诉求并非分布式协调或状态持久化，而是“有限次、带间隔、可超时的同步重试”。这种场景下，引入 Redis（如通过 BLPOP 或 Redisson RCountDownLatch）不仅过度设计，还会增加运维复杂度、网络依赖和故障面。
✅ 推荐方案：Spring Boot 原生重试机制（Spring Retry）
Spring Retry 是轻量、声明式、线程安全的重试框架，完美匹配本需求：
- 支持最大重试次数、退避策略（固定/指数）、异常类型过滤；
- 可与
RestTemplate或WebClient无缝集成； - 无需额外中间件，零运维成本；
- 逻辑内聚、易于单元测试与监控。
✅ 示例代码（基于 Spring Retry）
-
添加依赖（Maven）
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>
-
启用重试支持
在主启动类或配置类上添加注解：@SpringBootApplication @EnableRetry // 启用 Spring Retry public class ReceiptApplication { ... } -
封装签名获取服务（声明式重试）
@Service public class SignatureService { private final RestTemplate restTemplate; public SignatureService(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @Retryable( value = {HttpClientErrorException.NotFound.class}, // 仅对 404 重试 maxAttempts = 3, backoff = @Backoff(delay = 5000, multiplier = 1.0) // 每次间隔 5s（共最多等待 10s） ) public String fetchDigitalSignature(String txId) { String url = "https://api.signer.example/v1/signature?txId=" + txId; try { ResponseEntity<String> response = restTemplate.getForEntity(url, String.class); if (response.getStatusCode().is2xxSuccessful()) { return response.getBody(); } else if (response.getStatusCode().is4xxClientError()) { throw new HttpClientErrorException.NotFound("Signature not ready for tx: " + txId); } } catch (ResourceAccessException e) { throw new RuntimeException("Failed to connect to signature service", e); } throw new RuntimeException("Unexpected response for tx: " + txId); } @Recover // 重试失败后的降级逻辑 public String recoverSignatureFetch(Exception e, String txId) { log.warn("All retries failed for transaction {}, sending receipt without signature.", txId); return null; // 表示签名不可用，后续构建回执时跳过签名字段 } } -
在业务逻辑中调用
@Service public class ReceiptService { private final SignatureService signatureService; public ReceiptService(SignatureService signatureService) { this.signatureService = signatureService; } public Receipt generateReceipt(String txId) { String signature = signatureService.fetchDigitalSignature(txId); // 自动重试+降级 return Receipt.builder() .transactionId(txId) .timestamp(Instant.now()) .signature(signature) // 可能为 null .build(); } }
⚠️ 注意事项与最佳实践
-
避免盲目重试 5xx 错误：
5xx通常表示服务端临时故障，应谨慎重试（可单独配置），而404才是本场景的目标异常。 -
超时控制双重保障：
RestTemplate本身需设置连接/读取超时（推荐3s内），防止单次请求阻塞过久；@Backoff控制重试节奏。 - 幂等性前提：确保签名查询接口是幂等的（GET 方法天然满足），避免重复调用引发副作用。
- 可观测性增强：结合 Micrometer + Actuator 记录重试次数、耗时、失败原因，便于问题定位。
- 替代方案说明：若未来需跨服务/跨节点协同等待（如多个微服务共同等待同一事件），再考虑 Redis Pub/Sub 或分布式锁；当前单服务内同步等待，纯内存重试更优。
综上，Redis 并非本场景的合理选择——它解决的是缓存、队列、分布式锁等通用问题，而你的需求本质是“可控的客户端重试逻辑”。Spring Boot 原生生态已提供成熟、简洁、可靠的解决方案，应优先采用。
