写在前面每年 618、双 11 前后我们都会和客户一起做大促前的系统排查与活动复盘。这几年对接下来有一个感受越来越明确很多团队平时跑得挺好一到高峰就出问题往往不是因为流量太大扛不住而是平时没被重视的问题被大促放大了。下文整理三类我们最常见到、也最常帮客户提前排查的卡点。其中有些应对思路来自 VortMall自身在大促保障里的实践经验——尽量用同行能复用的方式讲清楚而不是堆概念。平时好好的一到大促就出问题我们接触的很多客户团队都有过类似经历日常下单、支付、发货都正常一到 618、双 11、周年庆页面变慢、下单失败、库存异常、客服爆满活动结束后再看系统又恢复平静于是很容易得出错误结论“就是大促流量太高扛不住也正常。”但真实问题往往不只是流量大而是系统平时隐藏的问题被高峰放大了。第一个坑把能下单当成能扛促销很多团队平时验证系统只关注功能是否可用商品能不能加购支付能不能成功后台能不能发货这些当然重要但它们验证的是功能正确性不是高峰承载能力。大促和普通日期的差异不只是访问量变多还包括同一商品被大量用户同时购买同一优惠券被集中领取同一活动页被短时间反复刷新下单后的积分、消息、库存同步量同步放大所以“平时能买和高峰能买”不是一回事。用户侧的真实感受用户并不关心后台发生了什么他们只会感受到页面转圈很久点击支付后没有反馈提示系统繁忙明明看到有货下单却失败抢到了券却用不了这些体验会直接转化为投诉、退款、流失甚至对品牌活动的负面传播。我们一般会怎么提前防帮客户做大促保障时我们很少一上来就讨论加几台机器而是先把热点链路拎出来活动页、爆款 SKU 详情、加购、下单、支付哪一段在并发下最先出问题就优先压哪一段。在 VortMall 的实践中我们会把热点读请求如秒杀活动信息、系统配置等做缓存或本地缓存减压避免所有流量都直接打到数据库下单、支付这类写操作则单独评估不和浏览流量绑死在同一瓶颈上。架构上网关、订单、支付可按服务拆分扩容体量较小的客户也可以先用单体聚合部署把核心交易跑稳不必还没做大就先背一整套重型设施。说到底大促保障不是平时能跑而是提前知道瓶颈在哪以及先保哪条链路。第二个坑库存和超卖活动前没被当成P0 风险库存问题是大促期间最伤信任的一类也是我们在客户复盘里见到最多、善后成本最高的一类。常见几种情况1. 显示有货下单失败用户会认为是耍猴或虚假库存。2. 超卖活动价卖出去了后面发现发不了货只能道歉、补偿、关单。3. 活动库存和普通库存混在一起导致秒杀库存被普通订单消耗或者反过来。4. 取消订单后库存恢复不及时造成明明没卖出去多少系统却说没货了。这些问题平时低频出现时不显眼但在秒杀、限时折扣场景里会被迅速放大。为什么库存问题特别麻烦因为它同时伤害三方用户体验差、信任下降运营活动效果被打折客服/仓储后续补救成本高而且库存问题往往还会牵连订单、支付、退款多个环节不是单点修复就能结束。我们一般会怎么提前防大促前如果把库存只当成一个数字大概率要出事。我们在项目里通常会和客户对齐三件事一是扣减粒度。秒杀场景下库存竞争往往集中在少数 SKU 上并发控制要细到商品级不能靠整站一把大锁硬扛否则页面没挂下单却全在排队。二是活动库存和普通库存分开管。满减、秒杀、限时价各自占多少量规则要提前定清楚别等活动开始才发现互相抢库存。三是失败提示要比平时更诚实。真没货了就明确告诉用户不要前台显示有货、下单才报错这是大促里最伤信任的一种体验。VortMall在库存处理上普通商品按SKU粒度扣减秒杀场景用独立活动库存高峰时走Redis原子扣减事务失败会自动回滚订单取消或未支付超时取消也会把库存还回去。大促前我们会重点过这条链路尽量把显示有货却下不了单和超卖后补锅挡在活动开始前。库存历来是我们帮客户做秒杀方案时最先过的一关比页面好不好看更值得花时间。第三个坑后续链路没有和活动主链路一起评估很多团队大促准备时会把精力放在活动页视觉优惠规则商品选品投放和直播这些都对但容易忽略一个事实用户感知的活动是否成功不取决于活动页是否好看而取决于从浏览到权益到账的整条链路是否稳定。比如用户参加满赠、返积分、抽奖、会员升级活动背后往往还有发券记积分改会员等级推送消息同步外部系统如果主链路扛住了后续链路没扛住用户仍然会觉得活动翻车了。这一点我们印象很深有些客户活动页和下单都扛住了但高峰后积分、券没到账的工单反而集中爆发客服压力一点没少。我们一般会怎么提前防主链路稳不代表活动就成功了。在VortMall里我们对不同后续动作会区分对待适合异步兜底的如订单超时自动取消、秒杀库存异步同步、自动确认收货会走 OutBox 模式——和业务数据同一事务落库再由定时任务投递失败可重试不容易无声丢失同步执行的如支付成功后赠送积分高峰时要单独纳入压测和复盘不能只假设主单成功就一定到账大促前我们通常会帮客户过一张「权益到账清单」积分、优惠券、赠品、会员成长值哪些活动绑了、峰值时会不会堆积、同步链路失败了有没有补救机制。很多团队不是没做这些能力而是从来没把它们和下单支付放在同一优先级上评估。小团队不是不能做稳而是要会抓重点资源有限时不必追求所有环节都做到极致但有几件事应该优先。这也是我们建议客户在大促前优先对齐的清单1. 先保护核心交易链路优先级最高的一般是商品浏览加购下单支付订单查询这些环节出问题直接影响成交。2. 对热点商品和热点活动单独评估不是整个商城都在被猛击往往是少数 SKU、少数页面、少数接口承受了大部分压力。大促前最值得排查的就是这些热点。3. 给客服和技术一个高峰预案包括哪些页面可能变慢哪些活动规则最容易被误解哪些异常可以自动恢复哪些必须人工介入出现超卖、重复支付、权益未到账时怎么处理没有预案高峰时所有人都会被动。4. 别把所有希望都压在临时扩容扩容当然有用但如果代码层、库存层、后续链路层有结构性问题扩容只能缓解不能根治。我们自己的体会是能拆的瓶颈先拆开能提前压测的先压测比活动当天临时升配更有效。一个更贴近业务的判断方式大促前我们通常会建议客户用用户视角做一轮简单自查用户动作需要确认的问题打开活动页首屏是否明显变慢抢券/秒杀会不会超卖失败后是否有明确提示下单支付高峰时会不会重复提交、重复扣款查订单支付成功后能不能尽快查到领权益积分、券、赠品是否可能延迟或丢失同步链路失败有没有补救找客服出现权益未到账时有没有明确的排查路径和补发规则这张表不复杂但比单纯讨论服务器够不够更接近真实问题。写在最后对大促来说最昂贵的不是服务器而是用户信任的一次性消耗。很多中小团队不是没努力而是把功能可用误当成了高峰可用。而高峰场景下的问题往往也不是突然出现只是平时没有被足够重视。如果你也在准备下一场大促建议别只问服务器要不要升配也问一问我们的热点链路有没有被单独评估过库存规则在极端并发下是否还成立用户支付成功后后续权益是否可能掉队把这三个问题提前想清楚比活动当天临时救火更有价值。有正在备战大促的朋友也欢迎在评论区聊聊你们目前最担心哪一环。本文由VortMall官方运营团队整理结合客户大促保障、活动复盘与平台自身实践经验仅供同行参考交流。