1. 概述与目标定义

目标：保证促销期峰值并发时页面可用率≥99.9%，响应时延P95≤1.5s。小分段：1) 明确站群范围（域名、流量入口、区域节点）；2) 制定SLA与关键指标（TPS、并发会话、错误率、CPU/IO/连接数）；3) 指定演练时间窗口与责任人名单（运维、开发、DBA、网络）。

2. 压测准备与执行（实操）

步骤1：准备环境（在非生产或镜像环境）。步骤2：使用工具与脚本：推荐k6或wrk，示例k6命令：k6 run --vus 2000 --duration 10m script.js；脚本要包含登录、下单、静态资源请求。步骤3：逐步推升并发（ramp-up），记录TPS/Latency/Errors。步骤4：记录瓶颈点并归类（CPU/DB锁/连接池/网络）。

3. 指标采集与分析方法

小分段：1) 必要指标：CPU、内存、NET/TCP状态、disk io、DB慢查询、Redis命中率、错误码分布；2) 使用Prometheus+Grafana收集并绘制SLO面板；3) 压测后生成火焰图和慢查询样本，优先处理响应时间分布异常处。

4. 边缘与CDN策略（静态与动态区分）

操作步骤：1) 将静态资源与图片全部上CDN，设置合理Cache-Control与基于版本的URL；2) 对动态页面使用边缘缓存或stale-while-revalidate策略（Varnish/Cloudflare Workers）；3) 检查并发回源限制、限制回源并发数，设置回源熔断规则。

5. 负载均衡与反向代理调优

实操细节：1) Nginx/Haproxy维度：增大worker_connections，调整keepalive_timeout，设置proxy_buffer_size；2) 修改Linux内核：sysctl -w net.core.somaxconn=65535；sysctl -w net.ipv4.tcp_tw_reuse=1；3) 配置会话粘性仅用于必要场景，优先无状态。

6. 应用层（代码与连接池）优化步骤

小分段：1) review关键请求代码，避免同步阻塞调用与N+1查询；2) 数据库连接池：调整最大连接数与超时，监控连接使用率；3) 开启GZIP/HTTP2、使用压缩与合并请求、提前编译模板与热加载关闭。

7. 数据库扩展与写入保护

实操指南：1) 读写分离：增加只读副本并配置应用的读库路由；2) 慢查询优化：使用EXPLAIN、创建索引或重写SQL；3) 大表改动用pt-online-schema-change或gh-ost，先在备环境验证；4) 写入高峰期限制批量化写或使用异步队列（Kafka/RabbitMQ）降峰。

8. 缓存层设计与运维细节（Redis/Memcached）

步骤：1) 缓存策略：热点key热点分片，使用local-L1+remote-L2，两级缓存降低Redis压力；2) Redis配置：最大内存策略（volatile-lru），关闭AOF在高写场景下使用RDB或混合策略并调整保存频率；3) 监控key过期/抖动，准备主从切换Playbook。

9. 弹性伸缩与发布策略

操作要点：1) 使用水平自动伸缩（ASG/Cluster Autoscaler），基于CPU/请求速率/自定义指标触发；2) 发布采用蓝绿或canary，提前验证流量切分规则；3) 预热策略：在促销开始前按预估流量先行拉起实例并预热缓存与JIT编译。

10. 监控、告警与Runbook

小分段：1) 建立告警分级（P0/P1/P2），明确联动组；2) Runbook示例步骤：确定问题→切换流量到备用池→增加副本→临时降级非核心功能→通知业务；3) 建立Runbook在Git并定期演练。

11. 故障应急与回滚实操步骤

步骤清单：1) 快速隔离：使用LB/NGINX下线异常节点；2) 回滚部署：如果canary失败，立即回滚到上一个稳定版本（kubectl rollout undo或切回旧LB规则）；3) 数据回滚：谨慎，优先修复兼容性与重放队列，避免直接回退主库数据；4) 事后复盘并更新防护策略。

12. 演练与团队协同要点

执行步骤：1) 定期做全链路混沌测试（chaos monkey）：关闭实例、限速回源、断DB连接；2) 预设通讯渠道（钉钉/Slack/电话树）与状态页模板；3) 演练结束后生成问题清单并分配整改任务。

13. 常见问答一

问：促销前48小时最重要的三件事是什么？

答：1) 完成一次全链路压测并修复关键瓶颈；2) 预拉伸资源并预热缓存（CDN与应用缓存）；3) 确认回滚/切流Runbook与责任人，保证告警与监控面板可见。

14. 常见问答二

问：发生数据库主库压力过大时，立即可做哪些操作？

答：立即限流写请求并开启队列化写入→增加只读副本分担读负载→下线慢查询源并临时关闭非必要写操作→根据情况切换到只读模式并通知业务。

15. 常见问答三

问：如何在高并发下保证支付/下单核心链路的可用性？

答：核心建议：1) 将支付/下单拆成幂等、异步可恢复的子流程；2) 使用单独的资源池（独立AP/DB/队列）和更高优先级的伸缩策略；3) 对外部支付方做熔断与降级策略（超时后回退到人工或延时确认）。

来源：技术运维视角日本站群在高并发促销期的稳定性保障方案分享