摘要：# CC攻击来了，多活和主备到底谁更能扛？别被PPT忽悠了 ˃ 一个网站被攻击时，多活架构像一支分散在不同地点的特种部队，而主备架构更像一个穿着厚重盔甲的骑士——前者灵活分散火力，后者则把所有希望寄托在一面盾牌上。 “网站又卡了！”技术群里突然弹出这条…

CC攻击来了，多活和主备到底谁更能扛？别被PPT忽悠了

一个网站被攻击时，多活架构像一支分散在不同地点的特种部队，而主备架构更像一个穿着厚重盔甲的骑士——前者灵活分散火力，后者则把所有希望寄托在一面盾牌上。

“网站又卡了！”技术群里突然弹出这条消息，紧接着是连续不断的抱怨。屏幕前的你心里一紧，赶紧打开监控面板——CPU使用率直接飙到98%，数据库连接数爆表，但带宽却异常平静。

这不是DDoS那种洪水猛兽，这是CC攻击，专挑你业务逻辑的软肋下手。

---

01 主备架构：那个“备胎”真的能救场吗？

咱们先聊聊最常见的主备架构。说白了，就是一套主力系统（主）加上一个备用系统（备）。平时主系统干活，备系统在旁边看着，数据实时同步。一旦主系统扛不住了——比如被CC攻击打趴下——就手动或自动切换到备系统。

听起来挺美，对吧？但这里有个大坑。

很多公司买高防IP，配个主备架构，就觉得高枕无忧了。我自己看过不少案例，问题往往不是没上防护，而是配错了防护。

CC攻击有个特点：它不冲带宽，专打你的应用层。攻击者模拟成千上万的正常用户，不停地访问你网站最耗资源的页面——比如搜索功能、商品详情页、登录接口。

主备架构在这种攻击面前，其实挺被动的。为什么？

因为攻击一旦开始，你的主系统资源（CPU、内存、数据库连接）会被迅速耗尽。这时候，即使切换到了备系统，攻击流量并不会自动停止。那些恶意请求会跟着你的服务IP，继续涌向备系统。

结果就是：备系统刚上线，几分钟内又被打趴下。然后呢？在两个系统之间来回切换，直到你找到真正的防护方案。

02 多活架构：分散风险，还是分散了防护能力？

多活架构就不一样了。它不是“一个主力加一个备胎”，而是多个系统同时在线服务，分布在不同的地域、不同的机房，甚至不同的云服务商。

用户请求通过智能DNS或者全局负载均衡，被分配到最近、最健康的节点。北京的用户访问北京节点，上海的用户访问上海节点。

这种架构在面对CC攻击时，有个天然优势：攻击者很难一次性打掉所有节点。

假设攻击者集中火力打你的北京节点，其他节点（上海、广州、深圳）还能继续服务。这时候，你可以把北京节点的流量逐渐调度到其他健康节点，同时在北京节点上进行攻击清洗。

但多活架构也不是万能的。它最大的问题是：贵。

不是一般的贵。你需要多套系统、多个机房、更复杂的同步机制（数据库多活、缓存多活、会话同步），还有那套智能调度系统。小公司根本玩不起。

03 真实场景下的对比：谁更能扛？

咱们别光讲理论，看几个真实情况。

去年我接触过一个电商客户，用传统的主备架构。大促期间被竞争对手用CC攻击，主系统5分钟就瘫痪了。切换到备系统，3分钟又挂了。最后是靠临时加钱买高防WAF的CC防护规则，才勉强撑过去——但损失已经造成了。

另一个客户是做在线教育的，用的是多活架构（三地四中心）。他们也遇到过CC攻击，攻击者集中打他们的杭州节点。他们的做法是：

第一步，在负载均衡层面，把杭州节点的权重调低，把流量往上海和深圳节点导。

第二步，在杭州节点前启用专门的CC防护，对请求进行人机识别（比如验证码、滑动拼图）。

第三步，分析攻击特征，在WAF上配置针对性的规则。

整个过程，用户几乎无感知。上海和深圳的用户继续正常上课，只有部分杭州用户可能会遇到验证码。

看到区别了吗？主备架构是“切换逃生”，多活架构是“带伤作战”。

04 那些PPT不会告诉你的细节

很多厂商在推销方案时，会把主备架构说成“高可用”，把多活架构说成“极致高可用”。但真到了被攻击的时候，你会发现几个关键问题：

数据一致性的坑。主备架构切换时，总会有那么几秒到几十秒的数据不一致。如果是金融交易，这几秒可能意味着资金损失。

会话保持的麻烦。用户正在下单，突然被切换到另一个节点，购物车空了——这种体验你遇到过吧？

防护成本的真实差异。主备架构你只需要保护一个主IP（备IP平时不暴露）。多活架构呢？每个节点都可能被攻击，每个节点都需要防护。你的防护预算要乘以节点数量。

05 该怎么选？别听厂商的，看你的业务

如果你是个中小企业官网、博客、展示类站点，业务量不大，但需要保证基本可用性——主备架构加个好点的高防WAF，其实够用了。

把防护重点放在WAF的CC规则上，设置好频率控制、人机识别、行为分析。别贪便宜买那种“不限量防护”的虚标产品，真被打的时候就知道什么叫“不限量的无效防护”了。

如果你的业务是电商、在线教育、游戏、金融——多活架构应该是你的标配，哪怕先从两地三中心做起。

但这里有个关键：多活架构不等于自动防住CC攻击。你还需要：

• 在每个节点前部署防护（WAF或者专门的CC防护）
• 建立实时的攻击监测和告警机制
• 准备好流量调度预案（别等到被打才临时配置）
• 定期做攻防演练，真的，很多公司的预案只在纸上有用

06 最后说点大实话

防护这东西，没有“银弹”。多活架构确实比主备架构更能扛CC攻击，但它的复杂度和成本也高出一个数量级。

我看到太多公司，明明是个小博客，非要上多活架构，结果防护没做好，运维先累垮了。也见过不少大公司，业务量巨大，却还守着老旧的主备架构，每次被攻击都手忙脚乱。

选什么架构，取决于你的业务值多少钱。别为了架构而架构，也别为了省钱而裸奔。

对了，如果你现在用的是主备架构，又经常被CC攻击困扰，我给你个临时方案：在DNS层面做故障转移，配合带CC防护的高防IP。虽然不如多活架构优雅，但至少比裸奔强。

防护这件事，永远是三分靠技术，七分靠预案。你的架构再先进，没有应急响应流程，没有定期演练，真出事的时候还是一团糟。

行了，不废话了。你的网站现在是什么架构？评论区聊聊，说不定我能给你点具体建议。