Java环境下无新增基础设施时处理服务宕机期间的WebHook请求方案

针对你描述的场景，在无法引入消息队列的前提下，可以从App B侧增强可靠性和App A侧容错处理两个方向入手，以下是具体实现方案：

方案1：App B侧实现本地持久化+定时重试机制 #

核心思路是让App B在发送请求失败时，将状态信息持久化到本地存储（无需额外服务），并通过定时任务重试发送，直到App A成功接收。

具体实现步骤： #

• 本地存储选型：使用轻量级嵌入式数据库（如H2、SQLite）或文件系统（JSON/CSV文件）存储待重试请求。Java应用推荐H2嵌入式模式，依赖小、操作简单。
• 重试逻辑：用Java原生ScheduledExecutorService或第三方库（如Guava Retryer）实现重试策略，设置重试间隔、最大次数，每次重试前可先检查App A的可用性（比如发送健康检查请求）。
• 幂等性保障：给每个状态请求生成唯一requestId，App A接收时根据requestId去重，避免重复处理同一状态。

简化代码示例： #

// 本地持久化DAO（基于H2嵌入式库）
public class FailedRequestDAO {
    public void save(String requestId, String status, String details) {
        // 插入H2表（表结构：request_id, status, details, create_time）
    }

    public List<FailedRequest> getPendingRequests() {
        // 查询未成功发送的请求
        return new ArrayList<>();
    }

    public void markSuccess(String requestId) {
        // 更新状态为已发送成功
    }
}

// 定时重试任务
public class RetryTask implements Runnable {
    private final FailedRequestDAO dao;
    private final RestTemplate restTemplate;
    private final String appAStatusUrl = "http://app-a/api/status";
    private final String appAHealthUrl = "http://app-a/health";

    public RetryTask(FailedRequestDAO dao, RestTemplate restTemplate) {
        this.dao = dao;
        this.restTemplate = restTemplate;
    }

    @Override
    public void run() {
        for (FailedRequest req : dao.getPendingRequests()) {
            try {
                // 先验证App A可用性
                restTemplate.getForObject(appAHealthUrl, String.class);
                // 发送状态请求
                restTemplate.postForObject(appAStatusUrl, req.getDetails(), String.class);
                // 标记为成功
                dao.markSuccess(req.getRequestId());
            } catch (Exception e) {
                log.warn("Retry failed for request {}: {}", req.getRequestId(), e.getMessage());
            }
        }
    }
}

// 启动定时任务（每5分钟重试一次）
ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(new RetryTask(new FailedRequestDAO(), new RestTemplate()), 
                             0, 5, TimeUnit.MINUTES);

方案2：App A侧实现状态回溯+主动拉取（需App B小改） #

如果App B可以新增简单接口，App A恢复后可主动拉取宕机期间的状态信息。

具体实现： #

• App B侧：用内存缓存（如Caffeine）临时保留最近24小时的状态记录，提供GET /api/history?startTime=xxx接口返回指定时间范围的状态。
• App A侧：启动时读取本地记录的最后处理时间，恢复后调用App B的历史接口拉取这段时间的状态，补全数据并触发后续任务。

注意： #

• 该方案依赖App B临时存储状态，内存缓存重启后会丢失，适合App B本身不频繁重启的场景。

方案3：HTTP幂等重试+本地磁盘缓存（轻量版） #

如果不想引入数据库，App B可使用带磁盘持久化的内存缓存存储失败请求，直接重试。

具体实现： #

• 用Caffeine配置磁盘持久化缓存，存储发送失败的请求（过期时间设为7天）。
• 用Guava Retryer实现指数退避重试策略，直到请求成功或过期。

简化代码示例： #

// 配置带磁盘持久化的Caffeine缓存
Cache<String, StatusRequest> failedRequestsCache = Caffeine.newBuilder()
        .expireAfterWrite(7, TimeUnit.DAYS)
        .writer(new CacheWriter<String, StatusRequest>() {
            @Override
            public void write(String key, StatusRequest value) {
                // 将请求写入本地文件实现持久化
            }

            @Override
            public void delete(String key, StatusRequest value, RemovalCause cause) {
                // 删除对应本地文件
            }
        })
        .build();

// 配置Guava重试器
Retryer<Void> retryer = RetryerBuilder.<Void>newBuilder()
        .retryIfExceptionOfType(IOException.class)
        .retryIfExceptionOfType(HttpServerErrorException.class)
        .withWaitStrategy(WaitStrategies.exponentialWait(1000, 10, TimeUnit.MINUTES))
        .withStopStrategy(StopStrategies.stopAfterAttempt(10))
        .build();

// 发送请求逻辑
public void sendStatus(StatusRequest request) {
    String requestId = UUID.randomUUID().toString();
    try {
        retryer.call(() -> {
            restTemplate.postForObject("http://app-a/api/status", request, String.class);
            failedRequestsCache.invalidate(requestId);
            return null;
        });
    } catch (RetryException e) {
        // 所有重试失败，存入缓存
        failedRequestsCache.put(requestId, request);
        log.error("All retries failed for request {}", requestId);
    }
}

选型建议 #

• 若App B是Java应用，优先选方案1，可靠性最高，嵌入式数据库开销极小。
• 若App B改动受限，优先选方案3，轻量易实现，适合快速解决问题。
• 若App A需要回溯历史状态，选方案2，但依赖App B新增接口。

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