不到 24 小时前，我写了一篇关于如何使用 Cloudflare 缓存加速您的网站的文章。不过，我已经将大部分逻辑转移到使用 Redis 的 Fastify 中间件中。以下是您自己执行此操作的原因以及方法。

Cloudflare 缓存问题

我遇到了 Cloudflare 缓存的两个问题：

• 启用响应缓存后页面导航中断。不久前我在 Remix 论坛上提出了一个有关此问题的问题，但截至撰写本文时，该问题仍未解决。目前尚不清楚为什么缓存响应会导致页面导航中断，但只有当 Cloudflare 缓存响应时才会发生这种情况。
• 我无法让 Cloudflare 在重新验证时执行服务陈旧内容，如原始帖子中所述。看起来这不是一个可用的功能。

我还遇到了一些其他问题（例如无法使用模式匹配清除缓存），但这些对我的用例来说并不重要。

因此，我决定使用 Redis 将逻辑转移到 Fastify 中间件。

[！笔记]
我将 Cloudflare 缓存留给图像缓存。在这种情况下，Cloudflare 缓存有效地充当 CDN。

Fastify 中间件

下面是我使用 Fastify 编写的用于缓存响应的中间件的带注释版本。

const isCacheableRequest = (request: FastifyRequest): boolean => {
  // Do not attempt to use cache for authenticated visitors.
  if (request.visitor?.userAccount) {
    return false;
  }

  if (request.method !== 'GET') {
    return false;
  }

  // We only want to cache responses under /supplements/.
  if (!request.url.includes('/supplements/')) {
    return false;
  }

  // We provide a mechanism to bypass the cache.
  // This is necessary for implementing the "Serve Stale Content While Revalidating" feature.
  if (request.headers['cache-control'] === 'no-cache') {
    return false;
  }

  return true;
};

const isCacheableResponse = (reply: FastifyReply): boolean => {
  if (reply.statusCode !== 200) {
    return false;
  }

  // We don't want to cache responses that are served from the cache.
  if (reply.getHeader('x-pillser-cache') === 'HIT') {
    return false;
  }

  // We only want to cache responses that are HTML.
  if (!reply.getHeader('content-type')?.toString().includes('text/html')) {
    return false;
  }

  return true;
};

const generateRequestCacheKey = (request: FastifyRequest): string => {
  // We need to namespace the cache key to allow an easy purging of all the cache entries.
  return 'request:'   generateHash({
    algorithm: 'sha256',
    buffer: stringifyJson({
      method: request.method,
      url: request.url,
      // This is used to cache viewport specific responses.
      viewportWidth: request.viewportWidth,
    }),
    encoding: 'hex',
  });
};

type CachedResponse = {
  body: string;
  headers: Record;
  statusCode: number;
};

const refreshRequestCache = async (request: FastifyRequest) => {
  await got({
    headers: {
      'cache-control': 'no-cache',
      'sec-ch-viewport-width': String(request.viewportWidth),
      'user-agent': request.headers['user-agent'],
    },
    method: 'GET',
    url: pathToAbsoluteUrl(request.originalUrl),
  });
};

app.addHook('onRequest', async (request, reply) => {
  if (!isCacheableRequest(request)) {
    return;
  }

  const cachedResponse = await redis.get(generateRequestCacheKey(request));

  if (!cachedResponse) {
    return;
  }

  reply.header('x-pillser-cache', 'HIT');

  const response: CachedResponse = parseJson(cachedResponse);

  reply.status(response.statusCode);
  reply.headers(response.headers);
  reply.send(response.body);
  reply.hijack();

  setImmediate(() => {
    // After the response is sent, we send a request to refresh the cache in the background.
    // This effectively serves stale content while revalidating.
    // Therefore, this cache does not reduce the number of requests to the origin;
    // The goal is to reduce the response time for the user.
    refreshRequestCache(request);
  });
});

const readableToString = (readable: Readable): Promise => {
  const chunks: Uint8Array[] = [];

  return new Promise((resolve, reject) => {
    readable.on('data', (chunk) => chunks.push(Buffer.from(chunk)));
    readable.on('error', (err) => reject(err));
    readable.on('end', () => resolve(Buffer.concat(chunks).toString('utf8')));
  });
};

app.addHook('onSend', async (request, reply, payload) => {
  if (reply.hasHeader('x-pillser-cache')) {
    return payload;
  }

  if (!isCacheableRequest(request) || !isCacheableResponse(reply) || !(payload instanceof Readable)) {
    // Indicate that the response is not cacheable.
    reply.header('x-pillser-cache', 'DYNAMIC');

    return payload;
  }

  const content = await readableToString(payload);

  const headers = omit(reply.getHeaders(), [
    'content-length',
    'set-cookie',
    'x-pillser-cache',
  ]) as Record;

  reply.header('x-pillser-cache', 'MISS');

  await redis.setex(
    generateRequestCacheKey(request),
    getDuration('1 day', 'seconds'),
    stringifyJson({
      body: content,
      headers,
      statusCode: reply.statusCode,
    } satisfies CachedResponse),
  );

  return content;
});

注释贯穿了代码，但这里有一些关键点：

• 缓存标准：
  • 请求：
  • 不缓存经过身份验证的用户的响应。
  • 仅缓存 GET 请求。
  • 仅缓存包含“/supplements/”的 URL 的响应。
  • 如果请求头包含cache-control: no-cache则绕过缓存。
  • 回复：
  • 仅缓存成功的响应（statusCode为200）。
  • 不缓存已从缓存提供的响应 (x-pillser-cache: HIT)。
  • 仅缓存内容类型为text/html的响应。
• 缓存密钥生成：
  • 使用包含请求方法、URL 和视口宽度的 JSON 表示形式的 SHA-256 哈希。
  • 在缓存键前加上“request:”前缀，以便于命名空间和清除。
• 请求处理：
  • 挂钩 onRequest 生命周期以检查请求是否有缓存的响应。
  • 提供缓存的响应（如果可用），并使用 x-pillser-cache: HIT 进行标记。
  • 发送缓存响应后启动后台任务刷新缓存，实现“重新验证时提供陈旧内容”。
• 响应处理：
  • 挂钩 onSend 生命周期来处理和缓存响应。
  • 将可读流转换为字符串以简化缓存。
  • 从缓存中排除特定标头（content-length、set-cookie、x-pillser-cache）。
  • 将不可缓存的响应标记为 x-pillser-cache: DYNAMIC。
  • 缓存响应的 TTL（生存时间）为一天，用 x-pillser-cache 标记新条目：MISS。

结果

我从多个位置运行了延迟测试，并捕获了每个 URL 的最慢响应时间。结果如下：

与 Cloudflare 缓存相比，Fastify 缓存速度较慢。这是因为缓存的内容仍然从源提供服务，而 Cloudflare 缓存则从区域边缘位置提供服务。然而，我发现这些响应时间足以实现良好的用户体验。