1. 高可用架构概述
高可用（High Availability, HA）是指系统在面对硬件故障、软件异常、网络分区等意外事件时，仍能持续对外提供合格服务的能力。在数据库缓存与异步任务编排场景中，任何一个环节的失效都可能导致数据不一致或业务中断，因此高可用是架构设计的核心约束。
1.1 可用性度量标准
业界通常用“几个九”来量化可用性，计算公式为：可用性 = (总时间 − 宕机时间) / 总时间 × 100%。下表列出常见等级及其对应的年度不可用时间：
| 可用性等级 | 年度宕机时间 | 典型场景 |
|---|---|---|
| 99%（2个9） | 87.6 小时 | 内部开发/测试环境 |
| 99.9%（3个9） | 8.76 小时 | 中小型业务系统 |
| 99.99%（4个9） | 52.56 分钟 | 金融核心、电商交易 |
| 99.999%（5个9） | 5.26 分钟 | 电信、支付清算 |
设计目标建议： 对于数据库缓存 + 异步任务编排系统，通常要求达到 99.99%（4个9）可用性。这意味着全年计划内+计划外停机不得超过 52.56 分钟，对故障检测、自动切换和恢复速度提出了极高要求。
1.2 单点故障（SPOF）
单点故障（Single Point of Failure）是指系统中某个组件一旦失效，将导致整个服务不可用。常见单点隐患包括：
- 单实例数据库：主库宕机后无法写入，缓存数据无法持久化。
- 单节点缓存：Redis/Memcached 单机故障导致缓存雪崩。
- 单任务调度器：异步任务编排中心宕机，所有定时/延迟任务丢失。
- 单网络入口：负载均衡器或 API 网关单点故障。
避坑提醒： 很多团队只关注应用层的冗余，却忽略了 DNS、NTP、配置中心、监控告警等基础设施的单点。在异步任务编排中，消息队列的 单副本 也是常见的隐蔽 SPOF。
1.3 冗余设计原则
消除单点故障的核心手段是冗余。以下是高可用架构中必须遵循的冗余设计原则：
- 主从/主备冗余：数据库、缓存、任务调度器均部署主备节点，主节点故障时备节点自动接管。
- 多副本一致性：冗余节点之间需保证数据最终一致或强一致，避免脑裂导致数据冲突。
- 故障自动检测与转移：通过心跳、健康检查、仲裁机制实现秒级故障感知，并触发自动切换。
- 无状态化：应用层尽量保持无状态，将状态下沉到数据库/缓存/消息队列，便于水平扩展和故障迁移。
- 隔离与熔断：冗余节点之间应做资源隔离（线程池、连接池），防止一个节点的故障扩散到整个集群。
实战口诀： “单点必冗余，冗余必检测，检测必切换，切换必验证。” 在数据库缓存 + 异步任务编排架构中，每一条链路都要画出故障切换路径，并定期进行混沌工程演练。
1.4 高可用架构总览
下图展示了数据库缓存与异步任务编排场景下的高可用核心组件及其冗余关系：