8.2 连接池与缓存策略

8.3 数据库连接池与缓存策略

在现代 Web 应用架构中，数据库与缓存系统构成了后端服务的“心脏”与“大脑”。前者负责持久化核心业务数据，后者则通过时空换算提升响应速度与吞吐能力。而在 Egg.js 这一以企业级 Node.js 应用为目标的框架生态中，如何高效、稳定、可扩展地管理数据库连接与缓存资源，直接决定了系统的性能天花板与运维复杂度。本节将深入剖析数据库连接池与缓存策略在 Egg.js 框架下的实现机理、工程实践与演进趋势，力图揭示其背后的设计哲学与技术权衡。

连接池：从资源争抢到优雅复用

设想一个高并发场景：每有用户请求抵达，应用便新建一条数据库连接，执行查询，再立即关闭。这种“即用即弃”的模式看似简单，实则暗藏危机。数据库连接的建立涉及 TCP 握手、身份认证、会话初始化等开销，频繁创建与销毁不仅浪费 CPU 与内存，更可能迅速耗尽数据库的最大连接数限制（如 MySQL 默认的 max_connections=151），导致后续请求被无情拒绝。

连接池（Connection Pool）正是为解决这一问题而生。其核心思想是预分配、复用、受控释放。Egg.js 本身并不直接提供数据库驱动，而是通过插件机制（如 egg-mysql、egg-sequelize、egg-typeorm 等）集成成熟的 ORM 或数据库客户端库，这些库内部通常已内置连接池实现。以 egg-mysql 为例，它底层依赖 aliyun-nodejs-sdk 或 mysql2，而后者提供了高度可配置的连接池能力。

连接池的工作流程可抽象为如下模型：

图注：数据库连接池的核心工作流程，体现了资源复用与容量控制的平衡机制。

在 Egg.js 中，连接池的配置通常位于 config/config.default.js：


exports.mysql = {
  client: {
    host: 'localhost',
    port: '3306',
    user: 'root',
    password: 'password',
    database: 'my_app',
    // 连接池关键参数
    pool: {
      min: 2,          // 最小空闲连接数
      max: 20,         // 最大连接数
      idleTimeoutMillis: 30000, // 空闲连接超时时间（毫秒）
      acquireTimeoutMillis: 60000, // 获取连接超时时间
      createTimeoutMillis: 30000,  // 创建连接超时时间
      createRetryIntervalMillis: 200, // 重试间隔
    },
  },
  app: true,
  agent: false,
};

这些参数绝非随意填写。min 值过低会导致冷启动时频繁建连；max 值过高则可能压垮数据库；idleTimeoutMillis 需权衡连接保活成本与重建开销。一个经验法则是：最大连接数应略高于数据库能承受的并发压力，同时结合应用的 QPS 与平均查询耗时进行动态调优。例如，若数据库能稳定处理 500 并发连接，而单次查询平均耗时 50ms，则理论最大 QPS 可达 \frac{500}{0.05} = 10,000 。此时若应用实际 QPS 为 2000，则 max 设为 100 已绰绰有余。

值得注意的是，Egg.js 的多进程模型（Master-Worker 架构）对连接池提出了特殊挑战。每个 Worker 进程都会维护自己的连接池实例。假设有 4 个 Worker，max=20，则理论上最多会向数据库发起 4 \times 20 = 80 条连接。这要求我们在规划数据库容量时，必须将进程数纳入考量。某些高级方案（如使用 Agent 进程统一管理连接池并通过 IPC 通信）虽能集中控制，但会引入额外的序列化与通信开销，需谨慎评估收益与成本。

缓存策略：穿透、击穿与雪崩的防御体系

如果说连接池解决了“如何高效访问数据库”的问题，那么缓存策略则致力于“如何减少访问数据库”。缓存的本质是以空间换时间，将热点数据存储在高速介质（如内存）中，从而避开慢速的磁盘 I/O。然而，缓存并非银弹，其引入也带来了新的复杂性——缓存穿透、缓存击穿与缓存雪崩，这三大经典问题如同悬在系统头顶的达摩克利斯之剑。

缓存穿透：指查询一个根本不存在的数据。由于缓存未命中，请求直达数据库，而数据库也查无此物，无法写回缓存。恶意攻击者可利用此特性，大量请求不存在的 key，压垮数据库。
缓存击穿：指某个热点 key 在失效瞬间，大量并发请求同时发现缓存为空，一拥而上查询数据库，造成瞬时高负载。
缓存雪崩：指大量缓存 key 在同一时刻失效，导致所有请求涌向数据库，引发连锁崩溃。

Egg.js 社区提供了多种缓存插件，如 egg-redis、egg-cache-manager 等，它们为构建健壮的缓存策略提供了基础工具。但真正的防御体系，需要开发者结合业务逻辑精心设计。

防御缓存穿透：布隆过滤器与空值缓存

对于穿透问题，一种朴素但有效的做法是缓存空值（Null Cache）。当查询数据库返回空结果时，仍将一个特殊标记（如 null 或 __EMPTY__）写入缓存，并设置较短的过期时间（如 1-5 分钟）。这样，后续相同请求将直接命中缓存，避免反复查询数据库。其代价是消耗少量内存存储无效数据。

更优雅的方案是引入布隆过滤器（Bloom Filter）。布隆过滤器是一种概率型数据结构，用于快速判断一个元素“绝对不在”或“可能在”集合中。我们可以将所有合法的主键 ID 预先加载到布隆过滤器中。当请求到来时，先查询布隆过滤器：

若返回“不存在”，则直接拒绝请求，无需查缓存或数据库；
若返回“可能存在”，则继续走正常缓存-数据库流程。

布隆过滤器的空间效率极高，且查询时间为常数 O(k) （ k 为哈希函数个数），非常适合前置拦截。Egg.js 中可通过 bloom-filters 等 npm 包实现，并在应用启动时由 Agent 进程加载全量 ID 列表。

防御缓存击穿：互斥锁与逻辑过期

针对热点 key 失效导致的击穿，核心思路是确保同一时间只有一个线程去加载数据。常用方法是在获取缓存未命中时，尝试获取一个分布式锁（如 Redis 的 SETNX 命令）。只有成功获取锁的线程才去查询数据库并回填缓存，其他线程则短暂等待后重试。

另一种巧妙策略是逻辑过期（Logical Expiration）。即缓存中不仅存储数据，还附带一个逻辑过期时间戳。读取时，即使物理 TTL 未到，若逻辑时间已过期，则异步启动一个后台任务去刷新数据，而当前请求仍返回旧数据。这种方式牺牲了部分数据实时性，换取了极高的可用性，适用于对一致性要求不苛刻的场景（如商品详情页）。

防御缓存雪崩：随机 TTL 与多级缓存

雪崩的根源在于缓存集体失效。最简单的缓解手段是为缓存的 TTL 增加随机扰动。例如，基础 TTL 为 30 分钟，则实际设置为 30 + random(0, 5) 分钟。这样，key 的失效时间被分散，避免了集中失效。

更进一步，可构建多级缓存架构。例如，L1 缓存使用本地内存（如 node-cache），TTL 极短（秒级）；L2 缓存使用 Redis，TTL 较长（分钟级）。即使 L2 缓存大面积失效，L1 仍能吸收部分流量冲击。Egg.js 的 app.cache 与 app.redis 可分别承担这两级角色，通过中间件组合实现分层防御。

图注：多级缓存架构有效分散风险，提升系统整体容错能力。

连接池与缓存的协同：构建弹性数据访问层

在真实系统中，连接池与缓存并非孤立存在，而是共同构成数据访问层的双支柱。一个精心设计的访问逻辑应遵循“缓存优先，连接池兜底”的原则：

读路径：先查缓存（多级），命中则返回；未命中则从数据库读取，并异步/同步回填缓存。
写路径：先更新数据库，成功后再删除或更新缓存（Cache-Aside 模式），避免脏读。

在此过程中，连接池的稳定性直接影响写操作的成功率，而缓存的有效性则决定了读操作对连接池的压力。二者相互依存，共同决定了系统的 SLA。

Egg.js 的 Service 层是封装这一逻辑的理想场所。例如：


// app/service/user.js
class UserService extends Service {
  async getUser(id) {
    const { ctx, app } = this;
    const cacheKey = `user:${id}`;
    // 尝试从 Redis 获取
    let user = await app.redis.get(cacheKey);
    if (user) {
      return JSON.parse(user);
    }
    // 缓存未命中，查数据库（使用连接池）
    user = await ctx.model.User.findByPk(id);
    if (user) {
      // 异步回填缓存，避免阻塞主流程
      app.redis.setex(cacheKey, 600, JSON.stringify(user));
    } else {
      // 防穿透：缓存空值
      app.redis.setex(cacheKey, 60, '__EMPTY__');
    }
    return user;
  }
  async updateUser(id, data) {
    const { ctx, app } = this;
    const cacheKey = `user:${id}`;
    // 先更新数据库
    const [updated] = await ctx.model.User.update(data, { where: { id } });
    if (updated) {
      // 再删除缓存，下次读时重建
      await app.redis.del(cacheKey);
    }
    return updated;
  }
}

这种模式清晰分离了关注点，同时利用了框架提供的基础设施。

8.2 连接池与缓存策略

8.3 数据库连接池与缓存策略

8.3 数据库连接池与缓存策略

连接池：从资源争抢到优雅复用

缓存策略：穿透、击穿与雪崩的防御体系

防御缓存穿透：布隆过滤器与空值缓存

防御缓存击穿：互斥锁与逻辑过期

防御缓存雪崩：随机 TTL 与多级缓存

连接池与缓存的协同：构建弹性数据访问层

最新进展与未来展望