2 篇博文 含有标签「alova-server」

你用 react-query 搭了前端，它的缓存和重试让浏览器那边很顺。后来你起了个 Node BFF 调三个下游服务，这些调用的重试和限流都落在服务端，而 react-query 在那儿根本不跑。这篇划清 react-query 的工作止步于哪、alova/server 从哪接手，并给出两侧的代码。

那条线​

react-query 活在浏览器里。它的 useQuery 重试、缓存、去重，全都发生在每个浏览器标签页里，绑着 React 的渲染周期。当你的 BFF 调下游时，这些逻辑在 BFF 内部一个都不执行。所以问题不是「react-query 还是 alova」，而是「服务端那层调用归谁管」。

重试：浏览器 vs BFF​

react-query 在浏览器里重试一个失败的查询：

useQuery({
  queryKey: ['resource', id],
  queryFn: () => fetch(`/api/resource/${id}`).then(r => r.json()),
  retry: 3,
  retryDelay: attempt => Math.min(1000 * 2 ** attempt, 8000)
});

这个重试护的是用户的视图。它对 BFF 出站调下游毫无作用，因为那次调用压根不经过 react-query。

在 BFF 上，alova/server 对出站请求做退避重试：

const { createAlova } = require('alova');
const { axiosRequestAdapter } = require('@alova/adapter-axios');
const { retry } = require('alova/server');

const alovaInst = createAlova({
  baseURL: 'https://downstream.internal',
  requestAdapter: axiosRequestAdapter()
});

const getResource = (id) =>
  retry(alovaInst.Get(`/resource/${id}`), {
    retry: 5,
    backoff: { delay: 1000, multiplier: 2 }
  });

// 在路由 handler 里：
const data = await getResource(req.params.id);

同一个思路，不同层。react-query 管浏览器，retry 管服务端。顺带一句：alova 的客户端 hook 在 uni-app / Taro / 小程序里也能跑同一套 useRequest，所以「浏览器/服务端分层」在内客户端也成立。

限流：只在服务端有​

react-query 完全没有「给 BFF 调下游做限流」这个概念，它的 API 里找不到「对服务 X 每秒最多 4 次」这种东西。那是服务端的事，而 alova/server 的 createRateLimiter 正是为它生的：

const { createRateLimiter } = require('alova/server');

const rateLimit = createRateLimiter({ duration: 4000, points: 4 });

app.get('/api/resource/:id', async (req, res) => {
  try {
    const data = await rateLimit(
      retry(alovaInst.Get(`/resource/${req.params.id}`), {
        retry: 5,
        backoff: { delay: 1000, multiplier: 2 }
      }),
      { key: `downstream:${req.params.id}` }
    );
    res.json(data);
  } catch (err) {
    res.status(429).json({ error: 'downstream busy, retry later' });
  }
});

rateLimit 在请求真正出去之前先扣一个点，被下游打趴的时候它不被你自己的流量埋了。默认存储是 method 的 l2Cache；跨实例时你换成一个共享存储（@alova/psc 或 redis），额度才是真正集群级的。

缓存：先搞清楚它活在哪一侧​

这是最容易被混的一点。react-query 的缓存是「每浏览器」的，它不让同一个用户在同一标签页里重复拉同一个资源，但对你 BFF 猛锤一个慢下游毫无作用，因为那次调用不在浏览器里。

alova 的缓存也是客户端策略特性：cacheFor 控制响应保留多久，模式只有 memory 和 restore，非 GET 请求默认是 null（不缓存）。在服务端，alova/server 给你的是 retry 和 createRateLimiter，它并不顺手塞给你一个下游响应的服务端缓存。如果你不想对重复的慢 GET 反复打下游，得自己加一层缓存（或倚仗下游自己带的），再把 retry/rateLimit 叠上去。

所以分工很干净：react-query 守浏览器缓存，alova/server 守 BFF 出站的重试和限流，互不相踩。

两个工具管的是不同层。请求止步于浏览器的地方用 react-query，BFF 那层交给 alova/server。要完整选型视角，见 react-query 与 alova 对比。

• 服务端重试策略
• 服务端限流

你跑着一个 Node BFF，夹在前端和三个下游服务中间。某天下午最大的那个下游开始回 429，你的 BFF 对每个 429 的回应是：立刻把同一个请求再发一遍。一分钟之内，下游被「它已经拒绝过的请求的重试」埋了，你的前端看到一整面 500。这场景熟不熟悉？

下面这种写法最容易把你带到沟里：

app.get('/api/resource/:id', async (req, res) => {
  try {
    const data = await fetch(`https://downstream.internal/resource/${req.params.id}`);
    res.json(await data.json());
  } catch (err) {
    // 朴素重试：现在就再发一次
    const retry = await fetch(`https://downstream.internal/resource/${req.params.id}`);
    res.json(await retry.json());
  }
});

它看起来人畜无害，直到出事。里面藏着两个问题：

1. 重试不看为什么失败。 429 的意思是「慢点」。立刻重试是慢点的反义词，你把你刚搞砸的那个状态又放大了一遍。
2. 没有客户端限流。 BFF 不管不顾地把每个进来的请求都转发给已经喘不上气的下游，没有任何东西给下游兜底。

如果你跑了不止一个 BFF 实例，手写计数器（模块级变量、内存 Map）也救不了你。每个进程各算各的，于是你以为的「每秒 4 次」上限，实际变成了每个实例每秒 4 次。三个节点加起来就是每秒 12 次。

这一层到底需要什么​

先别管库。一个扛得住限流的下游调用层，至少得有这些能力：

• 退避，而不是立刻重发。 等一会儿，再等比刚才更久。指数退避加一点抖动，能让所有实例别踩着同一个拍子重试。
• 重试要封顶、要挑失败。 试几次就停，而且只针对值得重试的失败（超时、5xx、429），对永远不成的 4xx 别浪费次数。
• 客户端限流。 在真正调用下游之前先查一份大家共享的额度，别往火里添柴。
• 计数器要跨进程。 这个额度得放在所有实例都认的地方，不是某个进程的内存里。

全手写的话，上面的 plumbing 不小。alova 的 server 端给了两个 hook，前三项直接覆盖，第四项靠一个可插拔的存储。

retry + createRateLimiter，一个中间件​

alova 是一套请求策略层。在服务端，alova/server 提供了包裹请求 method 的 hook：retry 加退避，createRateLimiter 加客户端限流。它们包的都是你本来就拿去调下游的那个 method 实例。

先建一个 alova 实例。服务端我用 axios 适配器，请求还是从 axios 出去，alova 只负责「怎么请求」这一层：

const { createAlova } = require('alova');
const { axiosRequestAdapter } = require('@alova/adapter-axios');
const { retry, createRateLimiter } = require('alova/server');

const alovaInst = createAlova({
  baseURL: 'https://downstream.internal',
  requestAdapter: axiosRequestAdapter()
});

// 每 4 秒窗口 4 个点，额度记在 method 的缓存存储里
const rateLimit = createRateLimiter({ duration: 4000, points: 4 });

然后包住下游调用。retry 放里面，rateLimit 放外面：

app.get('/api/resource/:id', async (req, res) => {
  try {
    const data = await rateLimit(
      retry(alovaInst.Get(`/resource/${req.params.id}`), {
        retry: 5,
        backoff: { delay: 1000, multiplier: 2 }
      }),
      { key: `downstream:${req.params.id}` }
    );
    res.json(data);
  } catch (err) {
    // 触发限流，或重试耗尽
    res.status(429).json({ error: 'downstream busy, retry later' });
  }
});

和朴素版比，改动在这几处：

• retry: 5 封了次数。backoff.delay: 1000 配 multiplier: 2，间隔拉成 1s、2s、4s、8s，被下游打趴的时候它喘口气，而不是立刻补第二刀。
• rateLimit 在请求真正到达下游之前先扣一个点。一个窗口里只有 4 个能过去，其余的会抛错、你早早回 429，下游不被你自己的流量压垮。
• key 把额度按下游资源分开，一个热点 key 不会把别的资源饿死。

retry 的默认值在这里也有意义：不传参数时它重试 3 次、每次隔 1 秒。我们改大，是因为这个下游够不稳定、值得多试几次。

集群那一块​

默认的限流存储是 method 的 l2Cache。单进程下就是内存，够用。跨实例时你把 store 指到一份共享存储，比如 @alova/psc 或 redis 适配器，所有节点从同一个额度里扣。这一块是手写内存计数器自己永远造不出来的，除非你专门去搭。

你能拿到什么​

不是基准测试，只是这份配置实际产生的行为：

最后一行是请求共享：alova 会把完全相同的并发请求去重，两个用户要同一个资源，不会触发两次下游调用。

如果你的 BFF 调的下游会限流，而且你跑了不止一个实例，上面这套组合值得花一个下午。

• 服务端重试策略
• 服务端限流