跨可用区部署金融级高可用的关键是构建故障可检测、可隔离、可切换的确定性流程，要求AZ间物理独立（供电/制冷/网络/空间），数据层强同步（RPO=0），负载均衡实时感知主从状态与同步延迟，应用层配合连接治理与幂等兜底。
要让跨可用区部署真正扛住金融级业务的可靠性压力，关键不是堆机器、铺链路，而是把“故障不可预测”这件事，变成“故障可检测、可隔离、可切换”的确定性流程。
跨可用区不是地理分散，而是故障域隔离
两个可用区（AZ）如果共用同一套供电系统、同一根光缆、甚至同一个机房楼体，那物理上再远，逻辑上仍是单点。金融级要求的是独立故障域：每个AZ必须有独立的电力、制冷、网络接入和物理空间。部署前必须确认云厂商或IDC提供的AZ之间无共享基础设施，否则所谓“跨AZ”只是假高可用。
数据层必须实现多AZ强同步，不能只靠异步复制
金融核心交易不允许RPO>0。主库写入必须获得至少一个跨AZ备库的同步确认才返回成功。金仓数据库的半同步复制、TDSQL的多副本强一致协议、Oracle Data Guard的Maximum Availability模式，都是为此设计。配置时需注意：
- 关闭纯异步模式，避免备库延迟积压
- 设置超时阈值（如500ms），超时则降级为本地同步，但触发告警并人工介入
- 同步链路走专线或SRv6隧道，禁用公网传输
流量调度必须与数据状态实时联动
负载均衡器不能只看节点存活（ping通就转发），而要感知数据库主从角色、同步延迟、事务提交状态。例如：
- 使用数据库HA组件（如Kingbase HA、Patroni）暴露健康端点，ELB/Ingress通过该端点判断是否可读写
- 备库同步延迟超过200ms时，自动将其从读流量池中剔除
- 故障切换期间，新主库需完成WAL重放并确认一致性后，才开放写入入口
应用层要配合做连接治理与幂等兜底
跨AZ切换可能伴随秒级连接中断或事务回滚。应用不能依赖数据库自动重试，而应：
- 使用带重连+事务重试策略的数据库连接池（如HikariCP配置
connection-timeout和validation-timeout） - 所有资金类操作必须带业务幂等键（如订单号+操作类型），防止切主瞬间重复提交
- 查询接口区分“强一致性读”和“最终一致性读”，前者直连主AZ，后者可路由至延迟容忍的备AZ
基本上就这些。
