解读

在国内金融、电商等高并发场景下，连接池泄漏是生产事故的“隐形杀手”。面试官想确认你能否：

1. 用Cloud SQL 原生指标第一时间发现泄漏；
2. 用Cloud Monitoring + Alerting做秒级告警；
3. 用Cloud Run / GKE 工作负载或Cloud Composer做自动重启，而不是人工登控制台；
4. 兼顾合规要求（等保、银保监）——重启必须留痕、可回滚。

知识点

1. Cloud SQL 实例级指标：database/mysql/postgresql/sessions、connections、connection_errors、max_used_connections、aborted_connects。
2. Cloud Monitoring MQL：可写滑动窗口率，如rate(sessions[5m]) > 0.9 * max_connections即视为泄漏。
3. Cloud Alerting Channel：支持钉钉、飞书、企业微信 webhook，满足国内“告警必达”要求。
4. Cloud SQL Admin API v1beta4：instances.restart 是幂等操作，重启期间主实例≤30 s 闪断，只读实例零中断。
5. Cloud Composer 2/Airflow：用PythonOperator调用 restart API，可前置快照备份（instances.export），满足等保“变更前备份”条款。
6. IAM 最小权限：重启服务账号仅需roles/cloudsql.editor，禁止绑定roles/owner，符合国内“最小可用”审计规范。
7. 连接池自查：Spring Boot 2.7+ 可暴露/actuator/hikaricp指标，通过Managed Service for Prometheus统一采集，与 Cloud SQL 侧指标做双向验证，避免误重启。

答案

分三步落地：

第一步：在Cloud Monitoring创建自定义指标
metric.type="cloudsql.googleapis.com/database/sessions"
用 MQL 写告警策略：

fetch cloudsql_database
| metric 'cloudsql.googleapis.com/database/sessions'
| group_by [resource.instance_name], [value_sessions_mean: mean(value.sessions)]
| condition val() > 0.9 * 'cloudsql.googleapis.com/database/max_connections'
duration: 300s

触发后写入Pub/Sub 主题 cloudsql-leak-alert。

第二步：部署Cloud Composer 2环境，编写 DAG：

1. 订阅上述主题，解析 payload 拿到 instance_id；
2. 先调用 instances.export 生成一致性快照（存到国内双可用区 Cloud Storage，命名带时间戳）；
3. 调用 instances.restart；
4. 重启成功后在钉钉群发送 Markdown 卡片：实例、原因、快照 URI、预计闪断时间；
5. 失败则走SRE 值班电话（通过阿里云语音通知转接，国内合规已备案）。

第三步：连接池侧兜底
应用使用 HikariCP，配置
leakDetectionThreshold=60000
metricsTrackerFactory=Micrometer
指标通过GKE 工作负载身份上传到Google Cloud Managed Service for Prometheus，与 Cloud SQL 指标做关联仪表盘。若应用层检测泄漏但数据库层未触发，则只重启 Pod，不重启 Cloud SQL，形成分层自愈。

拓展思考

1. 只读实例泄漏：上述策略仅对主实例生效，若只读实例被只读业务打满，可单独为只读实例建立只读连接池指标与只读实例重启 DAG，避免误杀主库。
2. 跨项目托管：国内大型国企常把 Cloud SQL 放在共享 VPC Service Project，重启 API 需走VPC-SC 边界，需在 DAG 里配置边界穿透白名单并加Access Level（IP 限定+2FA），否则会被组织策略拦截。
3. 零闪断重启：对银核心系统，可改用Cloud SQL 企业 Plus 版的在线内存补丁功能，先滚动重启备库，再主备切换，实现0 中断，但成本提升 35%，需做TCO 评估。