高可用架构不是靠堆资源硬扛流量，而是用分层防御、弹性响应和主动预判来化解不确定性。面对突发热点、恶意刷量或运营活动带来的流量冲击，关键在于让系统具备“自适应”的韧性——该拦的拦住、该放的放行、该扩的秒扩、该降的平稳降级。
限流与熔断：守住服务底线
流量洪峰最先冲击的是入口，没有前置控制，后端再强也会雪崩。
- Nginx网关限流适合做粗粒度防护，比如全站每秒最多1万请求，用漏桶算法防扫描攻击，配置简单见效快；
- Redis+滑动窗口更适合按用户ID、API Key或接口路径做细粒度限流，例如每个Key每分钟最多300次调用，能精准保护核心资源不被个别异常调用拖垮；
- 熔断器（如Sentinel）要监控下游依赖的失败率和响应延迟，一旦数据库或第三方服务超时率超50%，自动切断调用并返回兜底数据，避免线程池耗尽导致级联故障。
弹性伸缩：让资源随流量呼吸
服务器不是固定资产，而应是可调度的“潮汐劳动力”。
- 云平台的ESS（弹性伸缩服务）可基于CPU、内存、队列积压等指标自动增减实例，扩容动作从分钟级压缩到6–90秒内完成；
- 容器化部署（如Kubernetes）配合HPA（水平Pod自动伸缩），能根据QPS或自定义指标（如每秒消息处理数）实时调整服务副本数；
- 结合智能预测（如用历史流量+节假日模型），系统可在大促前1小时预热资源，避免扩容滞后带来的首波抖动。
多级缓存与异步解耦：削减真实压力
真正打到数据库或核心服务的请求越少，系统越稳。
- 构建“本地缓存（Caffeine）→分布式缓存（Redis Cluster）→CDN静态资源”三层体系，热点数据命中率提升后，回源请求可减少70%以上；
- 把发短信、写日志、生成报表等非关键路径任务扔进消息队列（如RocketMQ/Kafka），主流程毫秒级返回，后台慢慢处理，吞吐量翻倍且不影响用户体验；
- 对读多写少场景，采用读写分离+从库自动扩容，写库专注事务，读库横向扩展应对查询高峰。
容灾与自愈：故障发生时不停服
单点故障不可避免，但业务中断可以避免。
- 数据库用MySQL Group Replication或Redis Sentinel实现多节点自动选主，故障切换控制在5秒内；
- 应用服务跨可用区（Multi-AZ）部署，SLB自动隔离异常节点，健康检查间隔设为10秒以内；
- Kubernetes中配置Liveness Probe探针，容器卡死或假活时自动重启，配合Cluster Autoscaler还能在节点资源不足时自动加机器。
不复杂但容易忽略：所有策略都依赖可观测性。没有准确的指标采集、链路追踪和告警闭环，限流阈值调不准、扩容时机抓不住、故障根因找不到。高可用不是某个组件的功劳，而是监控、调度、治理、预案环环相扣的结果。
