CompletableFuture applyToEither 实现多机房首位响应

本文深入解析了 CompletableFuture 的 applyToEither 方法在多机房高可用架构中的关键应用——通过“首位响应”机制实现低延迟、高可用的服务调用，特别适用于主备机房（如上海/深圳）的读场景；但需警惕其本质是竞速而非容错合并，必须显式隔离IO线程池、手动处理空值与异常、并严防因数据同步延迟导致的“伪首胜”引发超卖等一致性风险，真正发挥其价值的前提是对业务一致性和架构约束的清醒认知。

applyToEither 本质是竞速，不是并行结果合并

applyToEither 的语义非常明确：只取两个 CompletionStage 中**先完成且正常返回**的那个结果，传给后续函数处理；另一个即使已完成或稍后完成，也完全被忽略。它不等待两者、不比较值、不兜底重试，纯粹是“谁快谁上”。这正适合多机房接口调用中“首位获胜”的场景——比如主中心（上海）和容灾中心（深圳）都提供同一服务，只要任一机房响应成功，就立刻返回，避免用户等待超时。

必须显式隔离线程池，否则 commonPool 会拖垮 IO 请求

多机房调用本质是网络 IO，而 ForkJoinPool.commonPool() 默认只配 Runtime.getRuntime().availableProcessors() - 1 个核心线程，且是守护线程，专为 CPU 密集型任务设计。若直接用 supplyAsync(() -> httpCall()) 不传线程池，所有 HTTP 请求会挤在 commonPool 里排队阻塞，反而比串行还慢。

• 为每个机房创建独立的 IO 友好型线程池，例如 Executors.newCachedThreadPool() 或更稳妥的 newFixedThreadPool(20)
• 调用时必须显式传入：CompletableFuture.supplyAsync(() -> shanghaiClient.get(id), shPool)
• 避免复用同一池子，防止一个机房慢请求拖累另一个机房的调度优先级

空值/异常不能靠 applyToEither 自动降级，得手动补逻辑

applyToEither 对异常无感知——如果先完成的是异常状态（如连接超时、500），它不会触发函数，而是直接让整个链路进入异常完成态。这意味着“首位获胜”可能赢了个 null 或抛了异常，但你真正要的是“首位非空且成功的结果”。

• 在 applyToEither 后接 filter + orTimeout + exceptionally 三层防护
• 示例关键片段：

  shFuture.applyToEither(szFuture, p -> p) // 先到先用
      .filter(Objects::nonNull) // 过滤 null
      .orTimeout(800, TimeUnit.MILLISECONDS) // 整体超时兜底
      .exceptionally(e -> {
          log.warn("双机房均未返回有效结果", e);
          return fallbackProduct(); // 降级逻辑
      });

• 注意：不要在 applyToEither 的函数参数里做判空，因为异常完成根本不会进这个函数

竞速结果不可预测，需警惕“伪首胜”带来的数据不一致

两个机房的数据同步存在延迟，上海机房返回的是最新库存（已扣减），深圳机房返回的是 3 秒前快照（未扣减）。此时 applyToEither 拿到深圳结果，用户看到的库存比实际多，可能引发超卖。这不是 API 用法问题，而是架构约束。

• 首位获胜只适用于「最终一致性可接受」的读场景，如商品详情页展示
• 写操作、强一致性读（如下单校验库存）必须走主中心，禁用 applyToEither
• 可在返回头中透出 X-Data-Source: shenzhen，便于问题排查时快速定位数据来源

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CompletableFuture applyToEither 实现多机房首位响应》文章吧，也可关注golang学习网公众号了解相关技术文章。