大流量攻击期间，临时限流与冗余切换都能争取恢复时间，却不是无代价的“开关”。限流过严会挡住正常请求，切换过急可能让备用系统也过载，甚至引发数据不一致。做好大流量攻击下业务连续性保障方法，关键是先判断瓶颈，再分层处置，并为每一步设定回退条件。
限流：止住请求，也可能挡住正常业务
限流通常在入口按来源、路径、用户身份或请求成本设阈值。以 Nginx 的请求速率限制为例，它能限制特定请求进入后端；但如果按单一来源地址设规则，共享出口下的多个正常用户可能被一起限速。若仅按路径限流，攻击者还可能转向其他昂贵接口。
需要防范的连续性风险
- 误伤：突发的真实访问也会触发限制，表现为请求被拒绝、页面反复重试或操作中断。
- 排队放大：允许请求排队不等于消除压力。等待时间变长后，客户端重试会增加请求量，形成更重负担。
- 规则盲区：只限制一个入口或一种请求特征，可能把压力转移到搜索、报表、文件处理等资源消耗更高的路径。
适合优先限流的情形，是系统仍可响应、压力集中在可识别的请求类型，且能观察拒绝比例与正常请求成功率。阈值可先参考平时同一时段的请求量和后端承载，再小步调整；促销、发布或周期性批处理等自然峰值会改变基线，不能把某个固定数值当成通用标准。
冗余切换：备用资源不一定接得住
冗余切换把请求转到另一实例、可用区或站点，适用于主节点故障或局部资源耗尽。但备用环境可能容量较小、配置不同，或依赖同一组数据库、网络和存储，切过去并未真正避开瓶颈。以 HAProxy 配合健康检查为例，检查阈值设得过敏，短暂延迟就可能造成节点频繁摘除与恢复；设得过宽，又会让故障节点继续接流量。
数据状态也要纳入判断。例如 PostgreSQL 使用异步复制时，主备之间可能存在复制延迟。切换后，已确认但尚未复制到备用端的写入可能缺失；若新旧主节点同时接受写入，还会产生冲突。因此，切换前要确认备用端健康、容量和数据状态，并明确谁有权写入。
按顺序执行，避免两种措施互相放大
- 确认压力位置：查看入口请求量、错误率、延迟，以及应用实例、数据库和连接池的资源情况；区分入口过载与后端依赖故障。
- 先保护关键路径：对高成本、可延后或非核心请求设较严格的临时限制；为必要操作保留容量，并同步观察正常请求的拒绝率。
- 评估切换条件：核对备用节点的健康检查、剩余容量、网络依赖和数据复制状态。只有目标环境确实可承载，才逐步转移流量。
- 小步验证并留回退：每次调整后观察延迟、错误率和资源占用。若备用端压力迅速上升，或正常业务成功率持续下降，停止扩展切换并恢复上一稳定配置。
- 解除临时措施：攻击压力下降后，逐步放宽限流、恢复节点，再检查积压请求、数据一致性和规则遗留，避免临时配置长期影响服务。
这套大流量攻击下业务连续性保障方法不要求先在限流和切换之间二选一：入口限流可以保护剩余容量，冗余切换可以绕开确认失效的资源；但应分阶段实施，避免把未经筛选的流量整体搬到备用端。
常见问题
限流和冗余切换哪个应该先做？
没有固定顺序。入口与后端仍健康、流量可识别时，可先做窄范围限流；主节点已故障且备用端经确认可用时，应执行受控切换。
限流阈值应该设多少？
按同一业务路径的基线、当前容量和正常请求成功率确定，先小幅调整并观察；不同系统和时段不存在通用阈值。
备用节点在线，就代表切换安全了吗？
不代表。还要核对可用容量、共享依赖、健康检查结果及数据复制延迟。
如何降低误伤正常用户的概率？
尽量按请求成本、路径或可信身份分层限流，并监控被拒绝的正常请求；不要仅凭单一来源特征封禁大范围流量。
归根结底，大流量攻击下业务连续性保障方法要同时控制入口负荷和故障扩散。限流看误伤与排队，切换看容量、依赖和数据状态；以监控结果逐步调整，并预先准备回退方案，才能降低连续性风险。
