乐闻世界logo
5月27日 16:18

Serverless 架构下数据库访问怎么优化？从连接池到冷启动的实战方案

核心挑战

Serverless 函数是无状态、短生命周期的计算单元，每次调用可能启动全新实例，这与传统数据库"长连接+连接池"的使用模式存在根本冲突：

  • 连接数爆炸：1000 个并发函数实例可能同时打开 1000 个数据库连接，远超 MySQL 默认 151 的连接上限
  • 冷启动延迟：新实例首次建立 TCP 连接 + TLS 握手 + 认证，耗时可达 200-500ms，占函数总执行时间的 30%-50%
  • 连接泄漏：函数超时或异常退出时，未关闭的连接占用数据库资源，最终导致 "too many connections" 错误

数据库选型：Serverless 原生 vs 传统数据库

Serverless 原生数据库

Aurora Serverless、DynamoDB、Cosmos DB 等数据库本身就是按需计费、自动扩缩容的架构，天然适配 Serverless 计算模型：

  • 自动扩展：Aurora Serverless v2 可在秒级从 0.5 ACU 扩展到 128 ACU，无需预置容量
  • 按需付费：DynamoDB 的 on-demand 模式按读写请求计费，空闲时成本趋近于零
  • HTTP 接入：Aurora Data API、DynamoDB API 基于 HTTP 协议，无需维护 TCP 长连接，从根本上规避连接池问题

传统数据库（RDS / PostgreSQL / MySQL）

传统数据库并非不能用，但必须解决连接管理问题。核心思路是引入中间层来复用连接，而非让每个函数实例直接连库。

连接管理优化

外部连接池代理

RDS Proxy 是 AWS 官方方案，它作为函数与数据库之间的代理层，核心机制是连接复用（multiplexing）：

  • 多个函数实例共享代理维护的连接池，1000 个并发函数可能只需要 50-100 个底层数据库连接
  • 代理自动处理连接建立、健康检查和故障转移，函数无需关心连接生命周期
  • 配置建议：空闲连接超时设为 30-60 秒，连接利用率目标 80%-90%，预留缓冲应对流量突增

Neon（Serverless PostgreSQL）采用类似思路，通过 WebSocket 连接池 + 分支隔离，支持毫秒级冷启动。

函数内连接复用

在函数代码中，将数据库客户端初始化放在 handler 外部的全局作用域：

shell
// 全局作用域 — 实例复用期间只执行一次
let pool;

exports.handler = async (event) => {
  if (!pool) {
    pool = mysql.createPool({
      host: process.env.DB_HOST,
      connectionLimit: 5,
      waitForConnections: true
    });
  }
  const conn = await pool.getConnection();
  try {
    const result = await conn.query('SELECT * FROM users WHERE id = ?', [event.userId]);
    return result;
  } finally {
    conn.release(); // 必须释放，否则连接泄漏
  }
};

关键点：conn.release() 必须放在 finally 块中，确保异常时连接也能归还池中。

Provisioned Concurrency 预置并发

对延迟敏感的核心接口，可配置预置并发（Provisioned Concurrency）：

  • AWS Lambda 保持指定数量的实例始终处于"热"状态，数据库连接预先建立
  • 代价是持续计费，适合 P99 延迟要求 < 100ms 的场景
  • 建议对核心链路（如下单、支付）启用预置并发，非核心链路（如日志处理）使用按需模式

访问模式优化

批量操作替代逐条请求

shell
// 差：N 次数据库往返
for (const id of userIds) {
  await db.query('SELECT * FROM users WHERE id = ?', [id]);
}

// 好：1 次数据库往返
const placeholders = userIds.map(() => '?').join(',');
await db.query(`SELECT * FROM users WHERE id IN (${placeholders})`, userIds);

批量操作将 N 次网络往返压缩为 1 次，在 Serverless 场景下收益更大——每减少一次数据库调用，就减少一次连接占用和计费时间。

缓存热点数据

DynamoDB DAX、Redis（ElastiCache Serverless）可缓存高频查询结果：

  • 读取频率远高于写入的数据（如配置信息、商品详情）是缓存的首选目标
  • 缓存命中率 > 90% 时，数据库负载可降低一个数量级
  • 注意缓存一致性：写操作需同步失效缓存，否则读到脏数据

读写分离

Aurora 集群支持读写分离：写操作走 Writer 端点，读操作走 Reader 端点：

  • RDS Proxy 可自动将读请求路由到只读副本，分散主库压力
  • 典型配比：1 个 Writer + 2-15 个 Reader，适合读多写少的业务场景

性能调优细节

索引与查询优化

  • 为高频查询字段建立索引，避免全表扫描——在 Serverless 环境下，慢查询不仅浪费计算时间，还在持续占用数据库连接
  • 使用 EXPLAIN 分析查询计划，关注 type 列是否出现 ALL（全表扫描）
  • 复合索引遵循最左前缀原则：INDEX(user_id, status) 可覆盖 WHERE user_id = ? AND status = ?，但无法覆盖 WHERE status = ?

异步处理写入操作

写入操作不一定要同步完成。将写入任务投入 SQS / EventBridge 消息队列，由异步消费者处理：

  • 接口响应延迟从数据库写入耗时（5-50ms）降至消息投递耗时（< 5ms）
  • 天然具备削峰能力，数据库不会因为写入洪峰而连接耗尽
  • 代价是最终一致性，需要业务侧接受短暂延迟

部署区域对齐

将 Lambda 函数部署在与数据库相同的可用区：

  • 跨可用区延迟约 1-2ms，跨区域延迟可达 50-100ms
  • 同区域部署可减少 TLS 握手和 TCP 建立时间，对冷启动场景尤其重要

面试回答要点

回答这道题时，建议按"问题认知 → 方案分层 → 场景选择"的逻辑组织：

  1. 先点明核心矛盾：Serverless 的无状态短生命周期与传统数据库的长连接模型冲突
  2. 再分层给出方案：数据库选型（Serverless 原生 vs 传统）→ 连接管理（代理池、函数内复用、预置并发）→ 访问模式（批量、缓存、读写分离）→ 性能调优（索引、异步、区域对齐）
  3. 最后结合场景决策：高并发读用 DynamoDB + DAX，关系型数据用 Aurora Serverless + RDS Proxy，成本敏感用按需模式，延迟敏感用预置并发
标签：Serverless