访问量具有明显时间规律的业务，应在高峰到来前完成流量预测、容量评估、限流降级和应急演练。本文从识别瓶颈、制定分层方案、上线前准备和高峰期监控四个方面，说明如何降低响应变慢、请求失败和数据重复提交的风险。
铁路12306放票、个人所得税申报截止日前、学校报名系统开放，以及大型活动预约开始时，访问量往往不是均匀增长，而是在某个时间点快速集中。此类业务的优势在于规律可识别，难点则是短时间内的并发请求可能同时冲击网络、应用、数据库和外部接口。真正有效的高峰期网络拥堵缓解方法，不是临时关闭功能，而是提前判断瓶颈并安排分层应对。
先判断：拥堵到底发生在哪一层
访问变慢不一定等于网络带宽不足。用户请求通常要经过域名解析、网络连接、负载均衡、应用服务、缓存、数据库和第三方服务，任一环节达到上限，都可能表现为页面打不开或提交失败。
用历史曲线确认高峰形态
至少整理近几次业务高峰的每分钟请求量、成功率、响应时间和错误类型。重点看高峰开始时间、持续时长、最高请求量，以及流量下降后系统多久恢复。若每天在相近时段出现相似曲线，可按“常态流量、预期峰值、突发峰值”建立三档容量，而不是只按照日均访问量估算。
区分网络、应用与数据瓶颈
- 网络层：出口链路利用率长期接近上限，连接建立失败或丢包增加，应检查带宽、负载均衡和连接数。
- 应用层：服务器资源尚有余量，但接口响应明显延长，常见原因是线程池、连接池或某个同步调用被占满。
- 数据层：查询耗时增长、锁等待增加或数据库连接耗尽，应优先优化查询、索引和读写分离，而不是单纯增加应用实例。
- 外部依赖：短信、支付、身份认证等接口变慢时，应设置超时、重试上限和备用提示，避免请求层层堆积。
把高峰业务拆成不同优先级
所有请求都采用同一套处理方式，容易让低价值操作挤占核心交易资源。建议按业务结果划分优先级：必须完成的登录、下单、缴费或报名属于核心链路；列表展示、推荐、统计和历史记录属于可延迟链路；日志导出、图片处理和批量通知则可以转为后台任务。
核心链路保持短而稳定
核心接口应减少同步步骤，尽量避免一次请求同时执行多次远程调用。可以先完成必要校验并返回明确结果，再将非关键工作放入任务队列。对重复提交，还应使用幂等标识，让同一用户的重复点击不会生成多笔订单或多条申请。
非核心功能主动让步
当负载接近预警线时，可暂时关闭个性化推荐、复杂筛选、实时排行榜等功能，改为展示固定内容或最近一次生成的结果。与直接返回空白页面相比，清晰说明“当前人数较多，请稍后重试”，通常更有助于减少用户连续刷新造成的二次冲击。
提前组合四类技术措施
- 流量预测：根据历史峰值、通知发布时间、预约名额和访问入口估算请求量，并为突发流量预留约20%至50%的余量。余量大小要结合业务波动、扩容速度和成本确定。
- 缓存设计：对变化不频繁的公告、地区列表和帮助文档设置缓存；对库存、余额、名额等强一致数据，不应只依赖缓存判断，必须回到可靠的数据源校验。
- 排队与限流：当瞬时请求超过处理能力时，可让用户进入排队页或采用令牌机制。读操作可以设置较宽松的额度，写入和扣款操作则应更严格，并配合退避重试，避免所有客户端同时再次请求。
- 弹性资源：提前确认应用实例、数据库连接、消息队列和存储空间的扩容方式。自动扩容通常需要数分钟生效，因此不能把它当作唯一方案，应在高峰前先扩容基础资源。
缓存适合重复读取且变化较慢的内容，限流适合保护有限资源，排队适合必须保留请求但无法立即处理的业务，弹性扩容适合资源瓶颈明确且平台支持快速增加实例的场景。它们不是互相替代的工具，常见做法是先缓存减压，再限流保护核心服务，同时用扩容承接可预测的增量。
上线前把方案变成可执行流程
- 提前一周或更早记录依赖清单，列出域名、证书、数据库、第三方接口和告警联系人。
- 在接近生产配置的环境进行压测，逐步提高并发，记录成功率、响应时间、资源使用率和错误原因。测试结果只适用于相同配置、请求比例和数据规模，不能直接外推到所有场景。
- 为每项措施设置触发条件，例如错误率连续数分钟升高、队列长度超过预设值或数据库连接持续接近上限。
- 明确回滚步骤，包括关闭新功能、降低非核心流量、恢复旧版本和暂停批处理，避免高峰期间临时讨论责任分工。
- 在正式高峰前检查扩容权限、配置生效时间和告警渠道，并安排人员观察高峰开始后的前十几分钟。
高峰期间重点看什么
不要只盯着访问量。应同时观察成功率、核心接口响应时间、排队长度、数据库等待、外部依赖耗时和用户重复提交数量。若访问量下降但响应仍未恢复，可能是队列、连接池或数据库锁等待尚未消退，此时继续导入流量反而会延长恢复时间。
高峰结束后，还要核对业务结果是否完整，例如订单是否重复、支付状态是否一致、预约名额是否准确。将实际峰值与预测值对比，记录哪一层先达到瓶颈，下一次才能调整容量和触发阈值。对有明显访问周期的业务，提前准备高峰期网络拥堵缓解方法，通常比故障发生后单独增加服务器更稳妥。
常见问题
访问量不大，为什么页面仍然很慢？
可能是单个接口查询效率低、数据库锁等待、第三方服务超时或连接池过小。应按请求链路定位，不要只根据总访问量判断。
限流会不会直接损失用户？
粗暴拒绝会影响体验。更好的方式是区分核心与非核心请求，提供排队位置、稍后重试时间或明确失败原因，并避免客户端高频自动重试。
缓存是否适合报名、库存和缴费业务？
公告和静态配置适合缓存；报名名额、库存、余额等数据涉及一致性，缓存只能辅助展示，最终提交必须由可靠数据源校验。
什么时候应该优先扩容，什么时候应该先优化代码？
若资源使用率高且请求处理逻辑稳定，可先扩容承接高峰；若某个查询或远程调用耗时异常，扩容只能延缓问题，应先优化瓶颈。
