一、什么是 Availability（可用性）
- Availability = 系统在一年中可正常提供服务的时间比例
常见两种表达方式：
百分比（99.9%）
N 个 9（three nines）
| 可用性 | 年宕机时间 | 说法 |
|---|---|---|
| 99% | ~3.65 天 | two nines |
| 99.9% | ~8.77 小时 | three nines |
| 99.99% | ~52 分钟 | four nines |
| 99.999% | ~5 分钟 | five nines |
核心认知：每多一个 9，成本会急剧上升
二、提升可用性的本质：冗余（Redundancy）
要提高可用性，就必须 增加冗余：
更多服务器
更多数据副本
更多数据中心 / 可用区
现实约束：
冗余 ≠ 免费
需要在“可用性”和“成本/收益”之间做取舍
三、单点故障（Single Point of Failure）
当前架构的问题
只有 1 台 EC2
即使：
DynamoDB 是高可用的
S3 是高可用的
EC2 挂了 = 应用完全不可用
结论：单实例 = 单点故障
四、最基础的改进：增加第二台 EC2
但位置非常关键
如果两台 EC2：
在同一台物理服务器 ❌
在同一个机架 ❌
在同一个数据中心 ❌
在同一个 AZ ❌
仍然可能一起挂
正确做法
- 部署在不同的 Availability Zone（AZ）
这样可以防止：
硬件故障
机架故障
数据中心级别问题
AZ 级别中断
五、多实例带来的新挑战（重点）
当你有多台服务器时，会遇到 三个新问题：
1️⃣ 配置与应用复制（Replication）
需要保证：
应用代码一致
配置文件一致
补丁版本一致
✅ 最佳实践：
自动化（CI/CD、AMI、启动脚本）
避免手工操作
2️⃣ 客户请求如何分发（Redirection）
方案一：DNS
一个域名 → 多个 IP
问题：
DNS 有 传播延迟
客户端缓存不可控
❌ 不适合快速切换
方案二：负载均衡（推荐）
- 位于客户端和服务器之间
优势：
自动健康检查
自动流量分发
无 DNS 传播延迟问题
📌 生产环境的主流选择
3️⃣ 高可用架构模式选择（必考）
六、高可用架构的两种模式
① Active–Passive（主备）
- 特点
同时只有一台在对外服务
另一台待命
- 优点
适合 有状态应用
会话始终在同一台服务器
- 缺点
资源利用率低
扩展能力弱
② Active–Active（双活）
- 特点
多台实例同时对外提供服务
流量分摊
- 优点
高可用 + 高扩展
性能更好
前提
应用必须是 无状态（Stateless）
会话数据存放在：
DynamoDB
Redis
数据库
Cookie / Token
📌 云原生架构的首选模式
七、有状态 vs 无状态（隐含重点）
| 类型 | 是否适合 Active-Active |
|---|---|
| 有状态（Session 在本机） | ❌ |
| 无状态（Session 外置） | ✅ |
八、核心结论速记（考试版）
Availability 用 % 或 “几个 9” 表示
提高可用性 = 增加冗余 = 增加成本
单 EC2 = 单点故障
高可用必须跨 Availability Zone
DNS 有传播延迟
负载均衡是首选
Active-Active 适合无状态应用
Active-Passive 适合有状态应用
