夜莺高可用与多机房
单节点夜莺、MySQL、Redis 或时序数据库故障都会影响查询、规则或通知。高可用设计要覆盖应用、元数据、缓存、数据源、边缘站点和通知出口，而不仅是增加 Web 副本。
1. 单节点风险
单节点可能因主机、磁盘、数据库、配置或网络故障造成控制台不可用、规则停止评估或通知中断。实验环境可接受，生产应定义允许丢失窗口和恢复目标。
2. Web 与 Server 高可用
将无状态 Web/API 放入负载均衡后部署多个副本，使用共享 MySQL/Redis 和一致配置。规则/调度组件的并发与 leader/任务协调能力依赖具体版本，部署前需验证是否支持多副本以及重复评估的行为。
3. 数据库与缓存高可用
MySQL 采用托管高可用或复制方案，具备备份、恢复演练和连接监控；Redis 使用适合业务的高可用、持久化和认证策略。TSDB 按 Prometheus/VictoriaMetrics 的容量、备份和跨集群查询方案独立设计。
4. 多机房与边缘
中心统一管理用户、规则和通知策略；边缘节点就近查询本地 TSDB 并执行规则，降低跨机房网络波动影响。统一 cluster、region、site 标签，验证规则同步、边缘心跳、通知去重和中心网络中断时的行为。
5. 大规模架构
大规模场景按团队、区域、数据源和租户划分责任边界，限制高基数查询和规则范围，使用 TSDB 长期存储能力，持续监控数据库、缓存、规则队列、查询延迟和通知失败。架构复杂度必须与实际规模、恢复目标和团队运维能力匹配。