VPS知识分享站先说结论：黑五能不能扛住，不取决于当天加了几台机器，而取决于你提前两周做了什么。顺序应该是“先压测拿基线 → 再堆缓存 → 再限流排队 → 最后才扩容”，扩容放在最后，是因为大部分站点在扩容前就能靠缓存和限流省掉一半压力。
时间点先对齐：2026 年黑五在 11 月 27 日，TikTok Shop 的黑五大促从 11 月 11 日就开打，真正的流量从 11 月上旬就开始爬坡。现在离黑五还有一个月，刚好够做一轮压测和一次演练。
第一步：先拿到基线
没有基线，后面所有扩容都是拍脑袋。至少测三个数：
- 单机 QPS：在正常响应时间下，一台机器能扛多少请求
- 拐点：QPS 到多少时 p95 开始飙升、错误率上升
- 瓶颈：先到顶的是 CPU、内存、数据库连接还是带宽
# 示例：用 wrk 压首页和商品页
wrk -t4 -c200 -d60s --latency https://example.com/
wrk -t4 -c200 -d60s --latency https://example.com/product/123
# 压测时同时看
top
ss -s
mysqladmin status读接口和写接口要分开压。商品页、搜索页是读，下单、支付、库存扣减是写，瓶颈通常不在同一个地方。目标峰值按日常峰值的 3 到 5 倍估，再留 30% 余量。
第二步：缓存能省掉一半压力
大促期间最划算的动作是缓存，不是加机器。按层次排：
- CDN：图片、JS/CSS、视频、可公开的静态页，尽量命中边缘
- 页面缓存：商品详情、分类页、活动页做短 TTL 缓存，登录态和购物车除外
- 对象缓存：Redis 缓存热点商品、库存快照、配置
- 数据库缓存：查询缓存、连接池、只读副本
缓存设计要提前想清楚三件事：key 怎么定、什么时候失效、穿透和雪崩怎么防。大促前把热点 key 预热，给不同 TTL 加随机值，避免同一秒全部过期。
第三步：限流和排队
缓存之后还有流量，就限流。限流不是“把用户挡在门外”，而是“把请求排好队，别让数据库先死”。
limit_req_zone $binary_remote_addr zone=bf:10m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=bfconn:10m;
server {
limit_req zone=bf burst=40 nodelay;
limit_conn bfconn 30;
}分层限流：静态资源宽松，商品页中等，登录/搜索/下单严格。下单可以加队列，前端显示排队进度，后端按数据库能承受的速度消费。秒杀类活动用令牌桶或 Redis 原子扣减，避免超卖。
第四步：扩容，扩在正确的地方
扩容前先确认应用是无状态的：session 放 Redis，上传文件放对象存储，定时任务别在多台机器上重复跑。满足这三点，加机器才有意义。
- 应用层：加实例，挂负载均衡，先灰度再全量
- 数据库：连接池、只读副本、慢查询优化；不要指望临时加从库解决写瓶颈
- 静态资源：全部走 CDN 或对象存储，别让应用服务器发图片
- 带宽：大促前确认出口带宽和流量包，别到峰值被限速
带宽和负载均衡也要提前确认。很多团队只盯着 CPU，结果峰值一来先撞到出口带宽或 SLB 的连接数上限。把大促期间的流量包、带宽峰值、回源带宽和证书到期时间列一张表，逐项确认，别等当天才发现被限速。
另外提前确认云厂商的配额和库存：要用的实例规格是否有货、快照和自定义镜像是否可用、弹性 IP 和负载均衡额度够不够。大促当天再申请配额，审批和库存都可能卡住，临时扩容会变成一句空话。
第五步：数据库和大促脚本
大促出事，十次有八次在数据库。提前做四件事：
- 开慢查询日志，把超过 200ms 的 SQL 全部过一遍，补索引
- 检查库存扣减逻辑，用事务或原子操作，保证不超卖、不重复扣
- 下单、支付、退款接口做幂等，防止重试造成重复订单
- 把报表、导出、对账这类重查询挪到从库或离线任务
第六步：预案和演练
写一页纸的应急卡：谁负责切流量、谁负责回滚、谁对外沟通、什么情况下触发降级。大促前至少演练一次“主库连接打满”或“某个接口超时”的场景，确认每个人知道去哪看、点哪里。
降级顺序建议：关非核心功能（推荐、评论、统计）→ 静态化活动页 → 限流加排队 → 切备用链路 → 最后才是扩容和回滚。每次变更都记录时间和操作人。
监控看什么
- 5xx 比例、p95/p99 响应时间
- 数据库连接数、慢查询数、锁等待
- Redis 命中率、内存、连接数
- 队列积压和消费速度
- CDN 命中率和回源带宽
- 订单创建成功率、支付成功率
告警阈值提前调低一点，大促期间宁可多响几次，也别等用户投诉才发现。
常见问题 FAQ
Q1：黑五当天加机器来得及吗？
来不及。加机器要经过镜像、启动、挂载、灰度，数据库也不一定能立刻分担。提前两周扩容并压测，当天只做小幅调整。
Q2：压测会不会把生产打挂？
会。压测要在预发或克隆环境做，至少不要打真实支付和库存。生产只能做小流量灰度。
Q3：缓存加多少层合适？
按业务需要，不是越多越好。CDN + 页面缓存 + Redis 通常够用；每加一层都要想清楚失效和一致性。
Q4：限流会不会误伤真实用户？
会，所以要分层。按 IP 限流会误伤 NAT 用户，按用户/设备/接口限流更精准；下单链路用排队而不是直接拒绝。
Q5：大促后要做什么？
把峰值数据、瓶颈、故障和成本写成复盘，更新容量模型和应急卡；该降配的降配，别让临时扩容变成长期账单。
总结
还有一条经验：大促前一周冻结非必要变更，把发布窗口关掉。很多故障不是流量打挂的，是当天上线的新代码打挂的。
黑五扛压的顺序是：压测拿基线、缓存挡大头、限流保数据库、扩容补余量、预案兜底。提前两周做，比当天临时加机器有效得多。把 502、DDoS、超售这些坑提前排掉，峰值来了才有余力处理真正的问题。
需要一台美国节点做压测或大促备用环境，可以按小时开一台萤光云美国 VPS，压完再释放。
