高可用架构需分层限流、单元化部署、缓存异步化及全链路可观测：Nginx+Lua令牌桶入口限流，Guava/Sentinel服务层细粒度控制，Redis原子扣库+MQ异步下单，用户ID哈希单元化隔离故障，压测与业务指标告警驱动运维响应。
要抗住双十一流量冲击，高可用架构不能只靠堆资源，关键是在流量进来前就“筛”、进来后能“扛”、出问题时可“切”，全程不卡顿、不雪崩、不超卖。
分层限流：从入口到核心层层设防
流量洪峰必须在最外层拦截，避免直接打穿后端。推荐三级限流策略：
- 接入层限流：用 Nginx + Lua 实现令牌桶限流，对秒杀接口单独设置 QPS 阈值（如 1000r/s），非核心接口（如商品评论）提前熔断
- 服务层限流：基于 Guava RateLimiter 或 Sentinel，在订单创建、库存扣减等关键方法入口做细粒度控制
- 数据层保护：Redis 设置连接池上限 + 命令超时；数据库连接池启用等待队列与拒绝策略，防止线程耗尽
单元化+异地多活：故障隔离与自动切换
把用户按 ID 哈希分到不同逻辑单元（如 u1、u2…u10），每个单元包含完整链路（商品、订单、库存、支付）。好处是：
- 单个单元故障不影响其他用户，故障影响面控制在 10% 以内
- 配合 DNS 或全局负载均衡，某机房宕机时，5 秒内自动将流量切到其他可用区
- 各单元数据库物理隔离，避免热点商品导致全库锁表
缓存与异步：把“同步压力”变成“异步流水线”
秒杀本质是“抢名额”，不是“立刻下单”。要把强一致操作压缩到最小范围：
- 用 Redis 原子命令（DECR）预扣库存，成功即发“抢中凭证”，失败立即返回
- 真正下单、写库、发通知全部丢进消息队列（如 RocketMQ），由后台消费者串行/分片处理
- 前端显示“排队中”或“已锁定”，不暴露真实库存，缓解用户刷新焦虑
可观测+预案：系统清醒的前提是人清醒
高可用不仅是技术方案，更是运维节奏。必须做到：
- 全链路压测覆盖核心路径，提前暴露瓶颈（如某个缓存节点延迟突增 30%，就优化它）
- 监控指标分级告警：CPU/内存/延迟是基础，更要盯住“Redis 库存 key 命中率”“MQ 积压数”“TCC Try 阶段失败率”等业务水位线
- 每类故障配明确 SOP：比如“库存服务超时 >5s 持续 1 分钟”，自动触发降级开关，返回预设兜底页
