解读

在国内面试中，这道题考察的是“可观测性+事件驱动”的落地能力。
面试官想知道你是否能把 Cloud SQL 的高可用事件（failover）主动推送到业务侧，而不是被动去查日志。
核心思路是：用 Cloud SQL 的自动故障转移事件 → Cloud Logging 接收 → Logging Sink 过滤并转发到 Pub/Sub → 业务消费者订阅并处理。
回答时必须体现“零侵入、低延迟、可灰度”这三个国内甲方最看重的指标，否则会被认为“不接地气”。

知识点

1. Cloud SQL 自动故障转移事件类型：
   cloudsql.googleapis.com/database.failover.start 与 failover.complete，二者均带 resource.labels.instance_id 与 jsonPayload.replicaLag 等关键字段。
2. Cloud Logging 的过滤语法：
   必须用 **protoPayload.methodName="cloudsql.instances.failover"` 或 logName="projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres.log" 并叠加 severity=INFO 才能精准命中，否则会把重启、日常切换也收进来。
3. Sink 授权：
   国内项目普遍用 独立服务账号（形如 service-PROJECT_NUMBER@gcp-sa-logging.iam.gserviceaccount.com），必须授予 Pub/Sub Publisher 角色，否则 Sink 创建成功但消息写不进 Topic，现场排障会被扣分。
4. Pub/Sub 订阅模式：
   金融客户要求 Exactly-Once，需开启 Pub/Sub 的“启用第一次尝试即成功” 并配合 Dead-letter topic（max_delivery_attempts=5），否则重复消息会被监管挑战。
5. 合规与灰度：
   国内多项目地要求 消息不出境，因此 Topic 必须创建在 上海/北京地域；灰度阶段用 Cloud KMS 自建 CMK 对消息做 端到端加密，面试时主动提及可加分。

答案

步骤如下，全部可在 Cloud Shell 一条脚本 完成，符合国内“可审计、可回滚”的交付规范：

1. 创建专用 Topic
   gcloud pubsub topics create cloudsql-failover-cn --project=PROJECT_ID --message-storage-policy-allowed-regions=asia-east2
   说明：asia-east2 对应 北京地域，满足数据驻留要求。

2. 创建 Logging Sink
   gcloud logging sinks create cloudsql-failover-sink \ pubsub.googleapis.com/projects/PROJECT_ID/topics/cloudsql-failover-cn \ --log-filter='resource.type="cloudsql_database" AND (protoPayload.methodName="cloudsql.instances.failover" OR jsonPayload.event_type="failover.complete")'
   说明：过滤条件已剔除日常主备切换，仅捕获真实故障转移。

3. 授权 Sink 服务账号
   复制上一步返回的 writerIdentity，执行
   gcloud pubsub topics add-iam-policy-binding cloudsql-failover-cn \ --member=WRITER_IDENTITY --role=roles/pubsub.publisher

4. 创建带死信的消费订阅
   gcloud pubsub subscriptions create cloudsql-failover-sub \ --topic=cloudsql-failover-cn --ack-deadline=60 \ --dead-letter-topic=cloudsql-failover-dlq --max-delivery-attempts=5

5. 业务侧消费示例（国内常用 Go）：
   使用 Pub/Sub Go SDK v1.30+，开启 Exactly-Once 选项，收到消息后先 幂等校验 failover_id，再回调内部工单系统。
   灰度阶段把 流量百分比 通过 Cloud Monitoring 自定义指标 控制，实现 可观测灰度。

6. 验收
   在测试实例手动触发故障转移：
   gcloud sql instances failover-test PROJECT_ID:INSTANCE_ID --async
   30 秒内能在 Pub/Sub 订阅 拉取到消息即算通过，SLA 符合国内金融 5 分钟内感知的要求。

拓展思考

1. 多云容灾：
   如果企业同时在 阿里云 RDS 做异地只读，可把 Cloud SQL 的 Pub/Sub 消息通过 Private Service Connect + VPN 转发到阿里云 MNS，实现 双云工单联动。
2. 成本优化：
   国内预算审批严格，可给 Topic 设置 30 天消息保留 + 批量投递，把 Pub/Sub 费用降低 40%；同时用 Cloud Functions 第二代 按实际调用计费，避免常驻 Pod。
3. 监管上报：
   央行 金融云备案 要求关键事件 5 分钟内上报，可在消费端再写一条 Logging Sink 到 BigQuery，用 Dataform SQL 生成 T+0 监管报表，面试时提及可直接对标 一行三会 的合规要求。