被 DDoS 攻击时，真正决定业务能不能继续的往往不是防护设备，而是”打挂之后能不能快速切走”。本文用 10 个问答讲清多活架构到底能不能防 DDoS、什么时候该切换、DNS 与数据同步有哪些坑、切换与回切的标准动作、怎么验证切换成功，以及小站有没有必要做多活。
Q：多活架构能防DDoS吗？
不能，两者解决的不是同一个问题。多活解决的是单点故障，DDoS 打的是入口带宽与连接资源。如果两个节点共用同一个入口带宽，攻击者同时打两个入口，结果是一样的。
多活的真实价值有三个：一是某个入口被打挂时能快速切到另一个；二是争取时间上高防、调清洗策略；三是让攻击者需要付出双倍成本。
结论：多活是兜底，不是防护。真正的防护还是 CDN 前置加流量清洗，多活负责”打不住的时候不至于全挂”。
Q：什么时候该切换？判定标准是什么？
三个条件同时满足才切：
- 攻击确认：流量或连接异常持续 5 分钟以上，且来源集中度、时间分布符合攻击特征。
- 现有防护打满：入向带宽超过 80%、连接表使用率超过 80%、P95 响应时间严重超时。
- 切换成本可接受：备用站容量足够、数据同步延迟在容忍范围内。
不要在第一次告警就切。DDoS 常见”试探加码”两段式，试探阶段流量不大，过早切换既浪费回切窗口，又把备用入口 IP 提前暴露。同时务必确认备用站 IP 没有公开暴露：不要有公开的 A 记录、不要在代码仓库或文档里出现、最好也挂在 CDN 后面。
Q：DNS切换为什么那么慢？
因为 DNS 解析要被三层缓存，TTL 只是上限不是保证：本地 DNS 缓存、运营商递归缓存、浏览器与系统缓存。
# 查当前解析与 TTL
dig +noall +answer www.example.com
# 用公共 DNS 交叉验证（排除本地缓存干扰）
dig +noall +answer www.example.com @8.8.8.8
dig +noall +answer www.example.com @223.5.5.5两个关键动作：TTL 要在平时就调好（网站记录建议 60 到 300 秒），攻击来了再改没用，旧值还在各地缓存里生效；重要接口不要只靠 DNS，可以再叠一层 HTTP 跳转或网关层切换，走应用侧控制。
还有一个常被忽略的点：攻击者也在盯你的 DNS。改完记录几分钟内新 IP 就可能被扫到，所以备用入口本身也要有防护，不能当”裸奔的后门”。
Q：多活的数据同步有哪些坑？
- 双向同步写冲突：自增主键、唯一索引、更新时间戳在双向写时必然打架。建议主库单向写、备站只读降级，或应用层先做分片。
- 文件与上传：两站各自存本地磁盘一定会不一致，统一走对象存储，两边读同一个桶最省事。
- 缓存冷启动：备站缓存是空的，切换瞬间全量回源，很容易把数据库打挂。要么提前预热热 key，要么备站先只读并排队放量。
- 会话丢失：会话存在单机文件或本地内存里，切过去全员掉登录。用 JWT 这类无状态方案，或集中式 Session。
- 回切数据缺口：切换期间在备站的写入如果没有回传主站，回切时这部分数据会丢，必须提前设计回传通道。
Q：切换前要准备什么？
- 一页纸预案：谁决策、谁执行、切换口令、回切条件、对外沟通话术，写清楚到能照着念。
- 检查清单：DNS TTL 已提前下调并生效、备用站容量与主站同量级、对象存储与数据库连通、证书未过期。
- 监控覆盖备站：把备站的资源、可用性、业务指标接进同一个面板，否则切过去等于闭着眼开车。
- 定期演练：每季度至少一次，在非攻击时段主动验证流程，记录实际切换耗时。
Q：切换动作怎么做才不丢用户？
顺序是先易后难、先只读后写入：
- 先切静态资源与只读页面，再切动态接口，最后考虑写入。备站不支持写就先公告”短暂只读”。
- 按地域或按比例灰度切，避免全量切换后发现问题无处可退。
- 保持 Cookie 域名与签名密钥一致，让用户切换后不用重新登录。
- 切换动作必须可逆，原入口保留待命，清洗到位后能立刻切回。
upstream app {
server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
server 10.0.1.11:8080 backup; # 主站不可用时自动接管
}注意 backup 只在主站全部不可用时才生效，它不等于”主动切换开关”。主动切换仍然要走 DNS 或负载均衡层，别把两种机制混为一谈。
Q：怎么验证切换真的成功了？
三个技术验证点，缺一个都可能是”假成功”：
- 多地解析一致：从多个地区、多个公共 DNS 查询，确认返回的新 IP 一致。只有本机生效说明 TTL 还没过期。
- 备站入口流量上涨：CDN 或负载均衡后台能看到流量确实进了备站。
- 主站源站入向回落：被打的入口入向明显下降，说明流量已经改道。
再加上业务验证：登录成功率、下单成功率、支付回调成功率回到基线水平。只看到”网站能打开”不算成功，关键业务链路通了才算。
Q：什么时候切回来？回切有哪些坑？
回切条件建议同时满足：攻击流量持续 30 分钟低于清洗阈值、源站资源恢复正常、高防或清洗能力已就位。
三个常见坑：
- 缓存冷启动：主站缓存早已过期，回切瞬间全量请求打到数据库。提前预热或分批回切。
- 数据差异：切换期间两边数据不一致，回切前先核对并同步差异，别把冲突带回来。
- 急于回切：宁可多观察一小时，也不要在攻击刚回落时马上切回，反弹一次成本更高。
Q：小站到底要不要做多活？
先算账：多活的成本约等于双倍服务器加双倍运维复杂度，多数小站投入产出比不划算。更合理的优先级是：
- 第一优先：藏源站。用 CDN 前置，源站只允许回源 IP 访问，这一步能挡掉绝大多数直接攻击。
- 第二优先：基础防护。WAF 加流量清洗，按需买防护套餐而不是自己堆机器。
- 第三优先：备份与快照。被入侵或数据被删时，备份才是真的救命。
- 最后才是多活。小站可以退一步做”轻量容灾”：静态站加对象存储、数据库定时快照，配合 CDN 多源站，成本低得多。
Q：还有什么补充建议？
- 把切换当固定动作来演练：写进应急预案，定期实操，记录每次的实际耗时与卡点。
- 备用站 IP 要当机密管理：不进代码仓库、不进公开文档、不进聊天记录。
- 监控备用站：长期不用的备用站最容易变成”证书过期、磁盘写满”的僵尸站，切换时才发现用不了。
- 提前对接清洗服务商：把升档、切高防的联系人和流程提前走通，攻击时才不会临时找人。
- 长期方向是让入口更抗打：CDN 多源、Anycast 调度，把”切不切”这个决策本身变轻。
一句话总结：多活不是防 DDoS 的手段，而是被打挂后的保命手段；切换靠的是提前调好的 TTL、对齐的数据和演练过的流程，而不是临时拍脑袋改解析。