如何强制重载Lambda函数全局变量？配置更新后刷新预热实例

这确实是个很头疼的问题——用全局变量缓存配置来提升性能、降低成本，但碰到配置更新时，预热实例抱着旧配置不放，重新部署又回到了最初想避免的繁琐操作。我整理了几个实用的方案，你可以根据自己的场景选择：

方案1：配置版本校验+按需/定时刷新 #

给你的DynamoDB配置加个版本标识（比如configVersion字符串或者lastUpdated时间戳），每次Lambda执行时先做一次轻量的版本校验，只有版本变化时才重新加载完整配置。

示例代码修改： #

let cachedConfig = null;
let cachedVersion = null;
const dynamoDb = new AWS.DynamoDB.DocumentClient();

async function getConfig() {
  // 先查询版本号，DynamoDB GetItem开销极低
  const versionResp = await dynamoDb.get({
    TableName: '你的配置表名',
    Key: { id: 'config_version' }
  }).promise();
  const currentVersion = versionResp.Item?.value;

  // 版本未变，直接返回缓存
  if (cachedConfig && cachedVersion === currentVersion) {
    return cachedConfig;
  }

  // 版本更新，重新加载完整配置
  const configResp = await dynamoDb.get({
    TableName: '你的配置表名',
    Key: { id: 'main_config' }
  }).promise();
  cachedConfig = configResp.Item;
  cachedVersion = currentVersion;
  return cachedConfig;
}

exports.handler = async (event) => {
  const config = await getConfig();
  // 你的业务逻辑代码
};

优缺点： #

• ✅ 实现简单，无需额外服务，成本几乎可以忽略（每次的版本查询是极小的开销）
• ✅ 兼容所有实例，不会有遗漏
• ❌ 不是实时刷新，有一定延迟（取决于你是否每次都校验，或者设置定时校验间隔），适合对配置实时性要求不高的场景

方案2：SNS触发主动刷新配置 #

当DynamoDB中的配置更新时，通过触发器发送SNS消息，让订阅了该主题的Lambda实例主动刷新缓存。

步骤： #

1. 在DynamoDB配置表上创建更新触发器，当配置项修改时，向指定SNS主题发送消息
2. 让你的Lambda函数订阅这个SNS主题
3. 修改Lambda代码，识别SNS消息并触发配置刷新

示例代码修改： #

let cachedConfig = null;
const dynamoDb = new AWS.DynamoDB.DocumentClient();

// 封装配置加载逻辑
async function loadConfig() {
  const resp = await dynamoDb.get({
    TableName: '你的配置表名',
    Key: { id: 'main_config' }
  }).promise();
  cachedConfig = resp.Item;
}

// 冷启动时先加载一次配置
loadConfig();

exports.handler = async (event) => {
  // 处理SNS刷新消息
  if (event.Records?.[0]?.EventSource === 'aws:sns') {
    await loadConfig();
    return { statusCode: 200, body: '配置已刷新' };
  }

  // 正常业务逻辑
  if (!cachedConfig) await loadConfig();
  // 你的业务代码
};

优缺点： #

• ✅ 接近实时刷新配置，配置变更后很快就能同步到活跃实例
• ❌ 需要额外配置DynamoDB触发器和SNS主题，增加了一点复杂度
• ❌ 无法保证所有预热实例都收到刷新消息（因为Lambda实例是弹性的，部分空闲实例可能没被SNS触发），建议结合方案1的版本校验作为兜底

方案3：利用Lambda环境变量做刷新信号 #

你可以保留一个特殊的环境变量（比如CONFIG_REFRESH_SIGNAL），当需要刷新配置时，更新这个环境变量的值（比如用当前时间戳）。Lambda的全局变量不会主动感知环境变量变化，但你可以在每次执行时读取这个环境变量，和缓存的信号值对比，不一致就刷新配置。

示例代码片段： #

let cachedConfig = null;
let cachedRefreshSignal = process.env.CONFIG_REFRESH_SIGNAL;

async function getConfig() {
  const currentSignal = process.env.CONFIG_REFRESH_SIGNAL;
  if (cachedConfig && cachedRefreshSignal === currentSignal) {
    return cachedConfig;
  }

  // 信号变化，重新加载配置
  const resp = await dynamoDb.get({...}).promise();
  cachedConfig = resp.Item;
  cachedRefreshSignal = currentSignal;
  return cachedConfig;
}

优缺点： #

• ✅ 无需额外服务，只需要更新环境变量（更新环境变量不需要重新部署Lambda，只是触发一次配置更新，不会重新打包代码）
• ✅ 所有实例都会在下次执行时感知到信号变化并刷新
• ❌ 环境变量更新后，需要等实例下次执行才会刷新，不是主动推送的实时刷新

综合来看，方案1+方案2是最稳妥的组合：用SNS实现大部分实例的实时刷新，再用版本校验兜底，确保所有实例最终都会拿到最新配置，同时避免了重新部署的繁琐。

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