TG咨询很多团队谈到电商大促流量承载，第一反应是估算活动当天的最高访问量，然后临时增加服务器数量。这个思路并非完全错误，却容易忽略一个事实：大促当天的故障，往往由平时就存在的架构问题放大而来。连接池偏小、缓存命中率不稳定、同步调用过多、日志写入阻塞，都可能在流量还没有达到理论峰值前造成超时。
为什么只看峰值容易判断失真
流量峰值通常只持续较短时间，而系统承受的压力由多个维度共同决定。商品列表主要消耗读取能力，结算页更依赖库存、优惠计算、地址和支付等服务；同样的访问人数，如果用户集中刷新同一款商品，缓存和数据库的压力也会明显不同。
因此，电商大促流量承载评估不能只写一个“每秒请求数”。至少要拆分为页面访问、搜索、详情读取、购物车操作、订单创建和支付通知等类型，并分别记录请求比例、平均响应时间、错误率、数据库连接数及消息积压情况。首页访问量很大，不代表订单服务一定承受同等压力；反过来，订单写入量不高，也可能因锁竞争导致整体变慢。
先把平时架构中的隐患找出来
检查缓存与数据库的边界
商品名称、图片地址、营销文案等变化较少的信息适合使用缓存，库存、订单状态和支付结果则必须以可靠的数据源为准。Redis 可以承担热点读取，但不能让缓存结果直接替代库存扣减。对缓存击穿、过期集中发生和热点键过载，应提前设置互斥更新、随机过期时间或分片策略。
数据库方面，要检查 MySQL 的慢查询、索引选择、事务范围和连接池上限。连接池并不是越大越好；连接数超过数据库实际处理能力后，排队和上下文切换反而会增加。应根据应用实例数、数据库可用连接数和单次请求持有连接的时间共同设定范围。
减少不必要的同步依赖
结算请求如果同步等待推荐、积分、短信或复杂画像服务，任何一个下游变慢都可能拖长主流程。可以把通知、埋点、发券等非核心动作放入异步队列，让下单链路只保留库存校验、价格确认和订单落库等必要步骤。异步队列能削峰，但必须配套重试上限、幂等键和失败补偿，不能把错误简单藏在队列后面。
容量评估应覆盖日常、突发和恢复
比较实用的做法是建立三组模型。第一组是日常基线，观察工作日和普通周末的请求分布、数据库写入量、缓存命中率及外部接口耗时；第二组是活动模型，按预估用户行为拆解浏览、搜索、加购和支付，而不是将所有请求都乘以一个放大倍数；第三组是异常模型，模拟缓存失效、单个服务超时、消息堆积和部分节点不可用。
容量压测应在接近生产配置的环境中进行，至少覆盖持续运行和短时突发两种情况。持续压测可以发现连接泄漏、线程池耗尽等问题，突发压测则用于验证弹性扩容和限流降级是否及时。测试结果要记录“还能承受多少请求”，也要记录在什么条件下开始出现错误，例如数据库写入延迟上升、队列等待时间变长或第三方接口达到调用上限。
大促前的可执行准备清单
- 梳理关键链路。画出从商品读取到订单完成的调用关系，标记库存、价格、支付等不可绕过的环节，以及可以延后或关闭的非核心功能。
- 核对资源边界。分别查看应用实例、线程池、数据库连接池、缓存节点、消息队列和网关的上限，确认扩容后不会把压力转移到下游。
- 设计分级保护。先对高成本接口做限流，再对推荐、评论、排行榜等非核心功能降级；核心订单接口要保留明确的超时、重试和幂等规则。
- 验证发布与回滚。使用小比例流量发布，观察错误率、延迟和数据库负载；出现异常时，应能在较短时间内回退版本或关闭新增功能。
- 准备人工操作手册。写清扩容、切换、暂停消费者、恢复缓存和核对订单的步骤，并指定值班人员和升级路径。
监控重点不是数字越多越好
监控应围绕用户结果和资源瓶颈建立。入口层关注成功率、分位响应时间和超时；应用层关注线程池、连接池和实例负载；数据层关注慢查询、锁等待、缓存命中率和复制延迟；队列则关注堆积量、消费速度和最早消息等待时间。指标最好能按接口和业务动作拆分，否则总平均值可能掩盖结算接口已经恶化的事实。
大促期间还要设置明确的触发条件。例如错误率连续一段时间超过基线、数据库连接长期接近上限，或队列等待时间持续增加时，自动或人工执行限流降级。这样做比看到单次尖峰后立即扩容更稳妥，也能避免误操作。
常见问题
问：平时流量不大，为什么还要做大促准备？
因为平时最容易发现并修复连接池、缓存策略、慢查询和同步依赖问题。临时扩容只能增加部分计算资源，不能自动解决架构瓶颈。
问：所有热点数据都放进缓存可以吗？
不可以。低频且稳定的数据适合缓存，库存、订单状态和支付结果需要可靠的一致性控制，缓存只能作为加速手段。
问：限流会不会直接损失订单？
合理限流的目标是保护核心链路。应优先限制重复刷新、低优先级功能和非必要请求，并向用户返回可理解的提示，避免整个站点一起超时。
问：没有完整压测环境怎么办？
可以先对关键接口做小范围、可回滚的验证，同时使用历史访问分布和生产配置估算瓶颈；但正式活动前仍应尽量补齐接近真实链路的测试。
归根结底，电商大促流量承载是日常架构质量的集中检验。峰值容量需要准备，平时的缓存、数据库、依赖治理、监控和回滚能力同样重要。只有把日常基线与活动突发结合起来，系统才不容易在尚未达到理论峰值时失稳。
