Next.js服务端HTTP请求间临时存储数据的最优方案

核心思路 #

受限于Serverless架构无法使用WebSockets的情况下，需围绕低延迟、高并发、自动回收这几个战斗系统的核心需求来选择临时存储方案，避免频繁操作数据库带来的性能瓶颈。

具体方案对比 #

1. 分布式内存缓存（优先推荐） #

用Redis这类内存缓存是最适配的方案，主流云服务商都提供托管版Redis，无需自行搭建独立实例，Next.js Serverless函数可直接通过环境变量配置连接。

• 实现方式：以战斗ID为Key，将会话数据存入Redis的哈希表/字符串结构，同时设置过期时间（比如战斗结束后5分钟自动清理）。
• 优势：读写速度比磁盘数据库快数倍，天然支持分布式，完美适配Serverless的无状态特性，高并发场景下表现稳定。
• 代码示例：

import { createClient } from 'redis';

// 初始化Redis客户端
const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

// 写入战斗会话数据
await redisClient.hSet(`battle:${battleId}`, {
  playerHp: 100,
  enemyHp: 200,
  currentTurn: 'player'
});
// 设置过期时间，自动销毁无效会话
await redisClient.expire(`battle:${battleId}`, 300);

2. Edge Runtime 内存缓存（仅限单实例场景） #

如果部署环境是单节点的Edge Functions（比如单实例Vercel Edge），可以用全局变量临时存储数据，但存在明显局限性：

• 风险：Serverless实例销毁后数据会丢失，多实例部署时请求可能分散到不同节点，导致数据不一致。
• 适用场景：仅用于测试或极低并发的小型游戏，不适合正式生产环境。
• 代码示例：

// 全局Map存储战斗会话（单实例可用）
const battleSessions = new Map();

export async function POST(request) {
  const { battleId, action } = await request.json();
  let session = battleSessions.get(battleId);
  
  if (!session) {
    session = { playerHp: 100, enemyHp: 200 };
    battleSessions.set(battleId, session);
    // 手动设置超时清理
    setTimeout(() => battleSessions.delete(battleId), 300000);
  }
  
  // 处理战斗逻辑...
  return Response.json(session);
}

3. 现有数据库方案优化 #

如果坚持使用数据库存储，可通过以下方式降低性能损耗：

• 使用内存表：比如MySQL内存表、SQLite内存模式，大幅提升读写速度。
• 加针对性索引：给战斗ID、过期时间字段建索引，减少查询耗时。
• 批量更新：将多次战斗操作合并为一次数据库写入，降低IO次数。
• 自动清理：用数据库定时事件或外部定时任务，自动删除过期的战斗会话数据。

选型建议 #

• 正式生产环境：优先选择托管版Redis，兼顾性能、可靠性和运维成本，完全适配Serverless架构。
• 测试/低并发场景：可临时使用Edge Runtime内存缓存，但需注意数据丢失风险。
• 依赖现有数据库：优化读写逻辑，尽量减少战斗过程中的数据库交互次数。

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