大促开始后，访问量上升只是第一层压力，真正容易出问题的往往是库存扣减、订单创建、登录验证和支付回调等关键链路。新手做电商大促流量防护时，首先要分清两个概念：扩容是提高系统能够处理的总量，限流则是在资源有限时控制进入系统的请求量。两者不是替代关系，而是“先准备容量，再保护边界”。
先判断：当前问题需要限流还是扩容
扩容适合处理可预期、且业务确实需要承接的增长。例如活动预热带来持续访问，应用实例、数据库连接池和缓存容量都还有明确的增长空间，此时可以提前增加实例或提高资源规格。扩容的优点是尽量保留用户请求，缺点是成本上升，而且数据库、支付接口等有状态或外部依赖未必能同步扩大。
限流适合处理瞬时尖峰、异常请求或超出下游承载能力的流量。例如秒杀按钮在同一时间被大量点击，若所有请求都直接进入订单服务，可能造成线程耗尽、连接池排队和整体超时。限流的优点是能保护核心链路，缺点是部分请求会被延迟、拒绝或提示稍后重试。
一个简单的判断顺序
- 查看最近活动或日常高峰的访问趋势，估算页面、登录、商品详情和订单接口分别会增加多少请求。
- 确认瓶颈位置：是应用处理能力不足，还是数据库写入、库存服务、支付渠道或网络出口已经接近上限。
- 对于可稳定增加的无状态服务，优先准备扩容；对于库存、订单等不能无限并发的链路，必须同时设置限流。
- 当外部服务响应变慢时，不要盲目扩容调用方，否则可能放大请求数量，应配合超时、重试上限和熔断降级。
电商大促流量防护要分层设计
有效的电商大促流量防护通常不是在入口放一个总开关，而是按业务重要性分层。商品介绍、搜索和活动说明页可以通过缓存、静态化或内容分发承接较多访问；购物车、优惠计算和订单提交属于交易链路，需要更严格的并发控制；支付和退款则应重点保证幂等、状态一致与结果可查询。
入口层：挡住无效和重复请求
可在反向代理或网关配置请求频率、单用户并发数和接口级配额。对于短时间内连续点击的提交请求，应使用请求标识或幂等键，避免同一订单被重复创建。验证码、登录校验和黑名单也应放在合适的位置，但不能把所有正常用户都置于复杂验证流程中。
业务层：保护真正稀缺的资源
库存扣减应采用明确的预占、确认和释放规则，并为超时订单设置回收机制。优惠计算可以先校验活动时间、用户资格和商品范围，再进入价格计算，减少无效请求占用数据库。对于非核心功能，如推荐、评论或实时排行榜，可在高峰期降低刷新频率，必要时暂时返回缓存内容。
扩容不能只看服务器数量
扩容前要画出请求链路：用户请求经过域名解析、入口网关、应用服务后，可能继续访问数据库、缓存、消息队列和第三方接口。只增加应用实例，却没有同步检查数据库连接数、锁竞争和写入吞吐，可能使故障从应用层转移到数据库层。
建议把容量拆成三类：第一类是无状态应用，可通过增加实例承接流量；第二类是有状态资源，如数据库和库存服务，需要评估读写比例、连接数与事务耗时；第三类是外部依赖，如短信、支付和物流接口，应按照对方约定的调用频率设置队列和重试策略。扩容后的实例还要检查启动时间、配置一致性、健康检查和日志量，避免新实例加入后立即出现配置错误。
大促前的可执行准备清单
- 建立基线。在正常业务时段记录页面响应、接口错误率、订单成功率、数据库连接使用率和消息堆积情况。具体阈值应根据自身系统确定，不宜直接套用其他平台的数值。
- 模拟峰值。使用压测工具分别测试浏览、登录、加购和提交订单，不要只做首页压力测试。压测环境应与生产隔离，测试数据也要避免触发真实支付或真实发货。
- 设置保护规则。为搜索、详情、登录、购物车和订单接口分别配置限流策略，并明确触发后返回排队、重试还是降级页面。
- 验证恢复路径。检查库存释放、支付结果补偿、订单查询和人工处理入口。系统恢复后，用户能否查到最终订单状态，比单纯追求短暂成功率更重要。
- 安排值守。活动期间按照入口、应用、数据和业务四个层面分工，保留变更记录。需要外部网络、云主机或线路支持时，可根据机房位置、服务范围和故障响应方式评估德讯电讯等服务商，重点看是否匹配自身部署条件，不应只比较宣传参数。
活动当天如何避免误判
监控应同时看技术指标和业务指标。技术侧关注请求量、错误率、超时比例、连接池、数据库锁等待和队列长度；业务侧关注商品详情成功率、加购成功率、订单创建结果、支付状态回写和取消订单数量。某个接口延迟升高，不一定代表需要扩容，也可能是依赖服务变慢或请求重试过多。
执行电商大促流量防护时，建议先降低非核心流量，再逐步扩大资源，而不是频繁修改多项配置。每次调整后至少观察一个完整业务周期；若错误率继续上升，应回滚最近变更并切换到预设的降级方案。活动结束后还要核对未支付订单、库存预占和支付异步通知，避免高峰过后出现数据问题。
常见问题
限流是不是意味着拒绝用户？
不一定。可以采用排队、分批放行、返回明确重试提示或只限制重复请求。关键是保护核心资源，同时让用户知道下一步怎么做。
服务器越多，系统就越稳定吗？
不是。数据库写入、库存事务和外部支付接口可能成为瓶颈。扩容前必须确认新增应用实例不会把压力集中转移到下游。
小型电商也需要做压测吗？
需要，但规模可以较小。至少应覆盖活动入口、登录、加购、下单和支付回调，并验证限流、超时和恢复流程。
大促当天可以临时修改限流参数吗？
可以，但应保留变更前配置、设置回滚方案，并一次只调整一个主要变量。没有监控和回滚条件时，不建议临时放开限制。
归根结底，电商大促流量防护的目标不是让所有请求无条件通过，而是在可承受范围内保障核心交易。把扩容用于承接合理增长，把限流用于保护稀缺资源，再用压测和监控验证边界，新手也能建立更可控的大促运行方案。
