企业官网建设流程全解析

双 11 前夜最危险的心态，是“平时跑得稳，大促应该也没问题”。LikeShop 这类商城系统在低并发阶段往往表现正常，一旦秒杀开场，库存超卖、订单重复、优惠券叠加失控、接口雪崩会在同一时间集中爆发。前夜不是从头做架构设计的时候，而是把已知风险点逐项钉死。下面这份清单按压测、库存、优惠券三条主线展开，每一条都尽量落到 LikeShop 的具体机制上，而不是泛泛的“加强监控”。

一、压测清单：不要只看 QPS，要看“哪里先崩”

1.1 压测指标基线

大促压测的目标不是“跑出一个漂亮数字”，而是找到系统的拐点和降级行为是否生效。建议把以下指标作为前夜必须确认的基线：

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 压测后的硬性动作

压测结束不是出个报告就完了。前夜必须完成：

1. 确认限流阈值已经配置，并且阈值与压测得出的容量匹配。LikeShop 的限流可以在 Nginx 层或应用层做，阈值建议设在压测安全水位的 80% 左右，留出 buffer。
2. 确认降级开关可用：关闭非核心功能（如商品推荐、积分抵扣）的开关是否能在 1 分钟内生效。
3. 确认 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_itemSETstock=stock-#{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 分钟看的

以上三条主线之外，还有一组“如果这里出问题，上面全白搭”的检查项：

双 11 前夜的清单不需要长，但每一条都应该是“没做就可能出事”的。LikeShop 的库存防超卖不是靠某一个“银弹”，而是 Redis 预扣、数据库条件更新、状态机回补、对账兜底四层协同；压测的目标不是刷一个峰值 QPS，而是确认拐点和降级开关真的能踩下去；优惠券的风险也不在“能不能领”，而在叠加规则和活动互斥有没有被翻到。把上面这些项逐条打勾，比大促当天盯着监控干着急有用得多。