拼团活动的高并发应对

为什么拼团链接总在开团那一分钟卡住？多数时候不是带宽不够，而是数据库先扛不住了。拼团的流量形状很极端：平时没人，开团瞬间涌进来，几分钟后又归于平静。 一、缓存预热 开团前把商品详情、拼团规则、库存数提前写进 Redis，别让第一波请求直接打到 MySQL： redis-cli SET group:1001:stock 500 库存扣减用 DECR 配合判断，扣成负数立刻回滚并回补。预热脚本放进发布流程，商品信息改了记得重跑一遍，否则用户看到的是旧数据。脚本执行完打印每个键的值做二次确认，防止半途失败没人发现。 二、读写分离 MySQL 配一主一从，写请求走主库，拼团进度、参与名单这类查询走从库，主库压力立刻减半。应用层用读写分离中间件，或在代码里区分数据源，两条路都行。注意复制延迟：用户开团成功后马上查订单，从从库可能读不到，关键路径要回主库读。主从延迟用 SHOW SLAVE STATUS 里的 Seconds_Behind_Master 监控，超过阈值就告警。 三、降级预案 预设一条底线：承载不住时宁可让部分用户排队，也不能把整个站点拖死。Nginx 层先限流： limit_req_zone $binary_remote_addr zone=tuan:10m rate=10r/s; 超出的请求返回静态排队页，写明"正在排队，请稍候刷新"。非核心功能比如推荐、评论先摘掉，保住开团和支付主链路，活动结束后再逐个恢复。降级开关提前演练一遍，真出事时一键切换，不临时翻文档。 四、资源与复盘 机器按峰值选，中型拼团用高防云服务器 S4-8G 这类内存宽裕的配置更稳，Redis 和 MySQL 与 Web 服务分开部署，互不抢资源。活动结束复盘三个数据：峰值 QPS、限流触发量、超时错误数，它们是下次扩容的直接依据。复盘记录归档，下次活动的容量规划直接引用。 拼团系统的要领就一句话：让热点数据离用户近一点，让主链路短一点。把这两点做到，剩下的都是常规运维。