高可用架构需分层限流、单元化部署、缓存异步化及全链路可观测：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 分钟”，自动触发降级开关，返回预设兜底页