双 11 前夜最危险的心态是“平时跑得稳大促应该也没问题”。LikeShop 这类商城系统在低并发阶段往往表现正常一旦秒杀开场库存超卖、订单重复、优惠券叠加失控、接口雪崩会在同一时间集中爆发。前夜不是从头做架构设计的时候而是把已知风险点逐项钉死。下面这份清单按压测、库存、优惠券三条主线展开每一条都尽量落到 LikeShop 的具体机制上而不是泛泛的“加强监控”。一、压测清单不要只看 QPS要看“哪里先崩”1.1 压测指标基线大促压测的目标不是“跑出一个漂亮数字”而是找到系统的拐点和降级行为是否生效。建议把以下指标作为前夜必须确认的基线维度检查项参考阈值/要求核心接口响应下单接口 P95≤ 500ms理想大促可放宽到 800ms 但需有降级预案成功率持续压测 2 小时下单成功率≥ 99.9%错误率非业务错误5xx、超时 0.1%超过则必须定位到具体环节资源水位CPU / 内存 / 数据库连接池CPU ≤ 70%连接池使用率 ≤ 80%留出突发余量恢复能力停止高压后回到正常响应的时间应在 1–2 分钟内恢复否则说明队列或连接池有积压LikeShop PHP 版尤其注意PHP 版在常规电商流量下完全够用但秒杀、大促的瞬时峰值需要靠 Redis 队列、限流、异步化去补不能指望 PHP-FPM 进程数硬扛。压测时如果发现 502/504 先于业务错误出现优先检查 PHP-FPM 的pm.max_children和 Nginx 的worker_connections。1.2 压测链路必须覆盖“全链路”单独压商品详情接口和单独压下单接口都不能说明问题。LikeShop 的请求链路设计为请求 → 限流 → Redis → MQ → MySQL压测必须沿着这条链路打。前夜至少确认以下场景已经跑过秒杀开场瞬时峰值RedisDECR是否稳定有没有出现连接超时订单创建 库存扣减 优惠券核销的串联链路任何一个环节慢都会把压力向后传递支付回调链路大促期间支付回调往往集中到达LikeShop 的支付回调必须做幂等压测时要模拟重复回调缓存失效场景手动清空热点 key 后观察数据库是否被打穿。LikeShop 对空值缓存和布隆过滤器的使用是为了防穿透压测时顺手验证一下这套机制是否真的在生效。1.3 压测后的硬性动作压测结束不是出个报告就完了。前夜必须完成确认限流阈值已经配置并且阈值与压测得出的容量匹配。LikeShop 的限流可以在 Nginx 层或应用层做阈值建议设在压测安全水位的 80% 左右留出 buffer。确认降级开关可用关闭非核心功能如商品推荐、积分抵扣的开关是否能在 1 分钟内生效。确认 PHP OPcache 已开启。生产环境开启 OPcache 对 PHP 执行效率有显著提升如果压测环境没开、生产才开压测数据会偏悲观反过来如果生产忘了开就是白白丢掉性能。二、库存清单LikeShop 的库存扣减不是“一个 update”LikeShop 的库存安全靠的是多层防护前夜要确认每一层都在它该在的位置上而不是只看最终库存数字对不对。2.1 Redis 预扣层LikeShop 秒杀采用 Redis 预减库存 异步队列的组合方案。前夜必须确认Redis 预扣 key 是否已预热秒杀库存的预热需要在活动开始前完成不能等用户请求进来才懒加载。多商户版尤其注意秒杀库存的预热要等平台审核通过后才能执行审核状态没走完的商品不会进入预热范围。预扣的原子性是否依赖 Lua 或DECR单纯GET再SET在并发下必然超卖。LikeShop 的核心流程是DECR判断库存不足直接返回售罄充足才进入后续队列。Redis 与 DB 的一致性兜底是否存在Redis 预扣成功不代表最终能落库必须有数据库层的条件更新作为第二道防线。2.2 数据库条件更新层LikeShop 在库存扣减上明确不推荐交易链路使用SELECT ... FOR UPDATE。悲观锁在 RR 隔离级别下可能产生间隙锁锁范围不可控事务里一旦有 RPC 调用锁持有时间会从毫秒级拉到几十毫秒高 QPS 下连接池很快耗尽。正确的姿势是条件更新 短事务UPDATEls_goods_itemSETstockstock-#{num}WHEREid#{itemId} AND stock #{num};受影响行数为 0 就回滚说明库存不足。前夜要检查 LikeShop 二开代码中交易链路上是否还有残留的lock(true)或FOR UPDATE如果有评估能否改成条件更新。2.3 回补与幂等层库存回补是最容易在“前夜看起来没问题、大促当天出问题”的地方。回补的触发点有四个超时关单、用户取消、退款成功、后台补货。前夜确认状态机 CAS 是否先于回补执行必须先成功迁移订单状态如待付款 → 已关闭再回补库存。反过来做如果状态迁移失败就会凭空多出一份库存。回补是否有流水唯一键兜底状态机保证“业务上只发生一次”流水唯一键保证“账本上只记一次”。两层幂等防的是不同层面的重复缺一不可。对账任务是否已配置活动期间建议每分钟一次数字级对账、每五分钟一次抽样明细对账活动结束后全量对账。前夜不需要写对账代码但必须确认对账脚本或任务已经就绪并且知道去哪里看差异。2.4 活动库存隔离如果上了秒杀/拼团LikeShop 多商户营销中心对秒杀采用独立库存池的设计活动期间不碰主库存活动结束后再把“秒杀库存 − 已售”的差额回补到主库存。前夜确认秒杀商品是否使用了独立的库存字段或库存表拼团如果共享主库存成团失败的回补逻辑是否已经过测试不要给所有商品都开活动库存隔离——隔离只应该用在确定性的大促商品上否则对账口径会复杂到把自己埋进去。三、优惠券清单配置错一条利润就漏一片LikeShop 的优惠券是“模板 实例”双层设计ls_coupon定义面额、门槛、发放时间、领取方式ls_coupon_list记录用户实际领取的每一张券。前夜检查优惠券重点不在“券能不能领”而在叠加规则和活动边界。3.1 优惠券与营销活动的互斥关系LikeShop 官方文档有一条硬限制优惠券暂不支持拼团、秒杀、砍价订单。前夜必须逐项确认双 11 主推的秒杀商品、拼团商品是否被错误地配置了可用的优惠券如果业务上确实需要在秒杀场景中使用优惠券是否已经通过二开显式放开并且测试过价格计算不会被重复抵扣满减满赠活动的叠加开关是否已经检查过。LikeShop 多商户高级版的活动支持配置“是否可与优惠券叠加”前夜要把每一个大促活动的叠加位翻一遍避免出现“满减 优惠券 会员折扣”三重叠加把单品打到负毛利。3.2 优惠券模板的关键字段逐项核对打开ls_coupon表或后台优惠券编辑页逐条核对以下字段condition_type/condition_money门槛类型和金额是否正确无门槛券是否被误设成了有门槛use_time_type固定时间、领券当天起、领券次日起三种类型在大促跨天场景下的实际可用时间是否符合预期get_num_type/ 领取上限是否允许同一用户无限领取大额券必须限制领取次数适用商品范围指定商品可用/不可用的配置是否覆盖了秒杀商品和拼团商品。3.3 优惠券库存与核销幂等优惠券超发和库存超卖的本质一样都是“先查再改”在并发下失效。前夜确认券的剩余数量扣减是否走原子操作而不是select出来再update核销是否有幂等键订单号 券 ID 唯一约束重复核销直接返回已核销结果而不是再扣一次已关闭的优惠券不能继续领取但已发放的券在用券时间内应能继续使用已删除的券则两者都不可用。前夜不要随意“删除”大促券要下架就点下架避免已领用户无法用券引发客诉。四、系统级兜底清单前夜最后 30 分钟看的以上三条主线之外还有一组“如果这里出问题上面全白搭”的检查项检查项具体动作.env生产配置APP_DEBUG必须为false数据库指向生产库缓存驱动指向生产 Redis运行目录与权限运行目录指向server/publicruntime/和uploads/具备写权限伪静态Nginx 的rewrite ^(.*)$ /index.php?s$1 last;生效内页不出现 404定时任务秒杀活动自动开启/结束、订单超时关闭、库存回补扫描等 crontab 已配置且时间正确活动状态机所有大促活动处于合法状态没有“待审核”的秒杀商品混在正式活动里备份数据库全量备份已完成备份文件可恢复mysqldump带--single-transaction监控告警Redis 连接数、MySQL 慢查询、PHP-FPM 进程数、订单创建失败率四项告警已开启通知到人双 11 前夜的清单不需要长但每一条都应该是“没做就可能出事”的。LikeShop 的库存防超卖不是靠某一个“银弹”而是 Redis 预扣、数据库条件更新、状态机回补、对账兜底四层协同压测的目标不是刷一个峰值 QPS而是确认拐点和降级开关真的能踩下去优惠券的风险也不在“能不能领”而在叠加规则和活动互斥有没有被翻到。把上面这些项逐条打勾比大促当天盯着监控干着急有用得多。
