跨可用区（多 AZ）高可用架构的关键设计点有哪些？

结论：多 AZ 的核心是把每个无状态层多副本打散到不同可用区、把有状态层做成跨 AZ 复制，并确保任一 AZ 整体故障时流量能在分钟级内切走。关键设计点：无状态化、数据复制策略、健康检查与自动摘除、容量冗余、常态演练。

展开：分层落实：1）接入层——云 LB 天然多 AZ（跨区负载均衡开启），入口健康检查要深（检查依赖而非 200 OK 的浅检查，防止"活着但全错"）；2）应用层——无状态（会话外置 Redis/客户端令牌），K8s 用 topologySpreadConstraints 把 Pod 均匀打散到各 zone，副本数 ≥ AZ 数；3）数据层最难——RDS/云数据库选 Multi-AZ 主备（同步复制，RPO≈0，自动 failover 分钟级），自建数据库要选复制拓扑（MySQL 半同步、PG 流复制 + Patroni），权衡同步延迟与可用性；跨 AZ 流量费是隐藏成本，chatty 服务要本地优先路由（topology-aware routing）。4）容量：N+1 起步——挂一个 AZ 后剩余容量仍能扛全量流量（3 AZ 部署每个 AZ 常态不超 50%）；5）演练：定期 AZ evacuation 演习（chaos engineering），没演练过的容灾默认不可用。易错点：多 AZ ≠ 多地域——AZ 故障域是供电/网络，地域级灾难（地震、区域云服务故障）要 multi-region + 数据异地复制，成本和复杂度高一个量级，按 RTO/RPO 需求分级投入。

追问方向：单元化架构（cell-based）与多 AZ 的关系、DNS 层故障转移（Route53 health check）的 TTL 与缓存不确定性。