Cloudflare Hyperdrive 连接池基础概念
很多时候业务数据库早已存在，可能是 AWS 上的 Postgres，也可能是自建机房里的 MySQL，这时让 Cloudflare Workers（Cloudflare 的边缘计算函数服务）直接连外部数据库会踩不少坑。Hyperdrive 就是为这种场景准备的，它在边缘维护连接池并缓存查询结果，让远程数据库用起来像本地一样快。
Workers 直连外部数据库的问题
先看直连方式会遇到什么。Worker 在每次请求里用驱动新建一条到外部数据库的 TCP 连接，跑完 SQL 后关闭。这条路径上有几段开销
| 开销来源 | 说明 |
|---|---|
| TCP 握手 | Worker 与数据库之间要三次握手，跨地域时往返延迟翻倍 |
| TLS 协商 | 数据库强制 TLS 时再多几个往返，握手耗时甚至超过查询本身 |
| 数据库认证 | 用户名密码校验、会话初始化，每条连接都要走一遍 |
| 连接数压力 | 每个请求开一条连接，高并发下数据库连接槽很快被打满 |
| 冷启动放大 | Worker 实例分散在全球，每个实例都要单独建连 |
实测一个跨大洲的 Postgres 连接，光是握手就要 300 到 800 毫秒，而一次简单主键查询可能只要 5 毫秒。握手开销远大于查询本身，这是直连最大的痛点。
数据库侧也有压力。Postgres 默认 max_connections 是 100，MySQL 默认 151，Worker 一旦流量上来就会把它们打爆，出现 too many connections 错误。
连接池原理
连接池的核心思路是复用连接。应用启动时先建一批连接放进池子，请求来了从池里借一条用完归还，不再反复握手。四个关键角色
| 角色 | 职责 |
|---|---|
| 池管理者 | 维护一组连接，负责借出和回收 |
| 空闲连接 | 握过手待命，可直接执行 SQL |
| 活跃连接 | 正在被某个请求使用 |
| 最小最大值 | 控制池大小，避免空闲浪费和上限击穿 |
传统部署里连接池跑在应用服务器上，比如 Node 进程里的 pg Pool。但 Worker 是无状态边缘函数，没有常驻进程，本地根本放不下连接池。这就是 Hyperdrive 出现的原因。
Hyperdrive 在边缘维护连接池
Hyperdrive 把连接池搬到 Cloudflare 边缘网络里，Worker 不再直连数据库，而是连到离自己最近的 Hyperdrive 节点，由 Hyperdrive 节点维护到数据库的长连接。整个链路是这样
Worker -> 边缘 Hyperdrive 节点 (连接池) -> 外部数据库具体做了三件事
第一，就近接入。Worker 总能找到同区域的 Hyperdrive 节点，这段内网调用延迟极低。
第二，连接复用。Hyperdrive 节点维护到数据库的持久连接池，多个 Worker 请求共享这些连接，握手只发生在池子初次建立时。
第三，连接数收敛。数据库侧只看到 Hyperdrive 节点的几条连接，不再被全球 Worker 实例直接冲击，连接槽压力大幅下降。
效果是握手开销被摊薄到几乎为零，Worker 拿到的连接是已经握过手的，直接发 SQL 就行。
Hyperdrive 与 D1 的区别
两者都让 Worker 用上数据库，但定位完全不同
| 对比项 | D1 | Hyperdrive |
|---|---|---|
| 数据库归属 | Cloudflare 托管 | 你自己的外部数据库 |
| 存储位置 | 边缘网络内 | 任意公网可达的服务器 |
| 连接方式 | Worker 直连，内网调用 | 经过 Hyperdrive 连接池转发 |
| 是否要迁移 | 要把数据导入 D1 | 不动现有数据库，只加一层代理 |
| 适用场景 | 新项目或想要边缘强一致 | 已有数据库不想迁移 |
| 数据库类型 | SQLite | Postgres、MySQL 等 |
简单说，D1 是 Cloudflare 自己的数据库，Hyperdrive 是连接你已有数据库的加速层。两者并不冲突，可以并存。如果业务数据库在 AWS RDS 上跑得好好的，没必要迁，挂一层 Hyperdrive 就能让 Worker 用得又快又稳。
缓存查询结果
除了连接池，Hyperdrive 还有一项重要能力是查询结果缓存。对相同的 SQL 语句，Hyperdrive 会在边缘缓存其结果集，下一次同样的查询直接返回缓存，连数据库都不用问。
缓存特性
| 特性 | 说明 |
|---|---|
| 缓存粒度 | 按完整 SQL 字符串匹配，参数不同视为不同查询 |
| 缓存时长 | 默认 60 秒，可在配置里调整 |
| 适用查询 | 读多写少、对短暂延迟容忍的查询 |
| 不缓存场景 | 写操作、显式标记不缓存的查询、结果集过大的查询 |
缓存特别适合列表页、配置项、字典数据这类高频读取的内容。配合连接池，一次查询可能根本不触达数据库，响应时间从几百毫秒降到个位数毫秒。
要注意缓存带来的是短暂不一致，60 秒内可能读到旧数据。对订单状态、库存这类强实时场景，要么缩短缓存时间，要么显式跳过缓存。
小结
Hyperdrive 解决的是 Workers 访问外部数据库的两个核心痛点，握手开销和连接数压力，方法是在边缘维护连接池。再加查询缓存，远程数据库在 Workers 里也能有本地般的响应速度。下一篇动手把一个真实的 Postgres 接到 Hyperdrive 上。
下一篇 接入外部数据库实战