解读

在国内云原生面试中，这道题考察的是“无状态容器并发”与“有状态数据库连接”之间的资源映射能力。
Cloud Run 的并发模型是“单实例多并发”，一个容器实例可同时处理 N 个 HTTP 请求；而 Cloud SQL 是“单连接单会话”，每个并发请求必须拿到一条 TCP 连接才能执行 SQL。
如果换算不准，就会出现“Cloud Run 实例还没扩容，连接池先被挤爆”的经典雪崩，因此面试官希望听到可落地的量化公式，而不是泛泛而谈“调大点就行”。

知识点

1. Cloud Run 并发维度
   • max-concurrency-per-instance：单实例同时处理的请求数，默认 80，上限 1000。
   • max-instances：最大实例数，受配额或预算限制。
2. 连接池维度
   • pool-size：进程级连接池同时保持的物理连接数。
   • Cloud SQL 连接上限：由数据库 tier 决定，如 db-f1-micro 仅 25 条，db-standard-4 可达 4000 条。
3. 国内网络特征
   • 华北、华东区域到 Cloud SQL 的 RTT 中位数 25 ms，连接复用收益高，池子不宜过小。
   • 部分金融客户要求 Private Service Connect + 自建 NAT，出口 IP 收敛，更易触发“单 IP 连接数上限 1000”的隐形配额。

答案

换算公式
所需最小池大小 = ⌈Cloud Run 并发数 × 单请求平均连接占用时长 ÷ 请求总耗时⌉
用符号表示：
P = ⌈C × Tsql / Ttotal⌉

变量说明

• P：单个 Cloud Run 实例里连接池的 maxPoolSize。
• C：Cloud Run 配置的 max-concurrency-per-instance。
• Tsql：一次请求生命周期内真正占用连接的时长，含 borrow、执行、归还，国内实测均值 35 ms。
• Ttotal：请求端到端耗时，含业务逻辑，国内均值 120 ms。

代入国内经验值
P = ⌈C × 35 / 120⌉ ≈ ⌈C × 0.3⌉
结论：池大小只需并发数的 30 % 即可安全复用，向上取整。

全局上限校验
总连接数 = P × max-instances ≤ Cloud SQL 最大连接数 × 0.8（留 20 % 缓冲给运维、后台任务）。
若结果超限，优先纵向升配数据库 tier，其次调低 C 或 max-instances，而不是盲目加大 P。

拓展思考

1. 分段池策略
   国内高并发零售场景，会把读/写拆成两个池：
   • 读池 Pread = ⌈C × 0.2⌉
   • 写池 Pwrite = ⌈C × 0.1⌉
     通过 HikariCP 的 poolName 做隔离，避免写事务阻塞读缓存。
2. 动态池伸缩
   利用 Cloud SQL 的 IAM-based auto-scaling trigger，当 CPU > 60 % 且连接使用率 > 80 % 时，通过 Cloud Function 把 maxPoolSize 热更新到 Secret Manager，应用监听文件变化秒级 reload，无需重启容器。
3. Serverless 新趋势
   如果业务已迁移到 Cloud Run jobs 或 Cloud SQL AlloyDB Omni，连接模型退化为“短连接 + 自动 IAM auth”，此时公式退化为 P = 1，连接池可被完全移除，但需接受 RTT 增加 15 % 的代价，适合凌晨批处理作业。