面对CC攻击，Web应用的内存缓存与数据库优化策略

摘要：## 面对CC攻击，你的数据库和内存缓存，可能正在“裸泳” 前两天，我帮一个做电商的朋友处理了一波CC攻击。攻击不算特别猛，但就那几百个“假用户”持续刷商品详情页，硬是把他的服务器CPU刷到了98%，数据库直接卡死，整个网站慢得像回到了拨号上网时代。…

面对CC攻击，你的数据库和内存缓存，可能正在“裸泳”

前两天，我帮一个做电商的朋友处理了一波CC攻击。攻击不算特别猛，但就那几百个“假用户”持续刷商品详情页，硬是把他的服务器CPU刷到了98%，数据库直接卡死，整个网站慢得像回到了拨号上网时代。

他挺委屈：“我上了高防IP啊，流量也清洗了，怎么还这么不经打？”

我登录后台一看，好家伙，防护策略是配了，可源站的Web应用本身，简直是在“裸泳”。每一次恶意请求，都像一把钝刀子，结结实实地砍在数据库上。防火墙是穿了防弹衣，可家里大门没锁，贼还是进来了。

说白了，很多防护方案，PPT上看着固若金汤，真到CC攻击打过来的时候，最先露馅的往往不是防护墙，而是你应用内部脆弱的数据处理逻辑。 内存缓存没用好，数据库查询没优化，这就好比用金库的门守着茅草屋，纯属浪费。

今天，咱就抛开那些“流量清洗”、“智能调度”的大词，聊点实在的：当CC攻击的“脏流量”绕过或穿透了外围防护，真正抵达你的Web应用时，你该如何靠内存缓存和数据库优化这两把“内家功夫”，扛住压力，甚至做到波澜不惊？

内存缓存：不是“有没有”，而是“怎么用”

首先得破除一个迷信：上了Redis或Memcached，就等于有了缓存。真不是这么回事儿。 缓存策略配错了，比不用还糟。

• 场景一：缓存穿透——给数据库“递刀子” 这是CC攻击最爱的伎俩。攻击者疯狂请求一个根本不存在的数据，比如 /product?id=-1 或 id=9999999。你的缓存里没有，请求就会每次都直接砸向数据库。 这就坏菜了。 数据库每次都要做一次全表扫描或索引查找，最后返回一个“空”。这种查询开销极大，瞬间就能把数据库连接池打满。 怎么办？

  1. 布隆过滤器（Bloom Filter）上场： 在查询缓存和数据库之前，加一层布隆过滤器。它可以用极小的内存，快速判断一个数据“绝对不存在”或“可能存在”。对于那些“绝对不存在”的恶意ID，直接在应用层就返回空，连缓存都不查，更别说碰数据库了。这就相当于在门口装了个智能识别器，一眼认出捣乱分子，不让进门。
  2. 缓存空对象（Cache Null）： 对于查不到的数据，也在缓存里存一个特殊的“空值”或短TTL（生存时间）的标记。下次同样的恶意请求过来，直接从缓存拿到这个“空”，保护数据库。但要注意设置较短的过期时间，并监控这类空键的数量，防止缓存被垃圾数据占满。

• 场景二：缓存雪崩——自己把自己“送走” 想象一下，你给一堆热门数据设置了相同的缓存过期时间（比如都是凌晨2点）。平时没事，可万一在CC攻击的节骨眼上，这批缓存同时失效了。所有请求瞬间涌向数据库，数据库当场就可能猝死。 这简直是自己制造的灾难。 怎么办？ 太简单了，给缓存过期时间加个随机抖动。比如，原本统一缓存1小时，现在改成 1小时 + 随机(-5分钟, +5分钟)。让缓存失效的时间点错开，压力就平摊了。这个细节，很多团队都会忽略，但关键时刻能救命。

• 场景三：热点Key打爆单节点——木桶的短板 如果你的缓存是集群部署，但某个明星商品（或某个被CC攻击盯上的API路径）成了超级热点Key，所有请求都集中打向集群里的某一个节点。得，这个节点就是木桶的短板，它一过载，整个缓存服务性能骤降。 怎么办？

  1. 本地缓存（Local Cache）救急： 在应用服务器本地内存（比如用Caffeine、Guava Cache），对极热的数据再做一层缓存。对于CC攻击中反复请求的同一个资源，大部分请求在应用服务器本地就解决了，连分布式缓存网络都不用进。注意，本地缓存的数据一致性要设计好，适合短时间极少变动的数据。
  2. Key拆分： 把一个热点Key拆成多个子Key，散列到不同节点。比如 product:hot:123 拆成 product:hot:123:part1、part2，访问时再聚合。这招有点“技术流”，但对付极端热点很有效。

数据库优化：让查询“飞起来”，而不是“躺下去”

缓存是第一道缓冲，但总有些请求是必须落到数据库的（比如复杂的条件查询、写入操作）。这时候，数据库本身的健康度就成了生死线。

• 索引，索引，还是索引！ 这几乎是老生常谈，但我见过的案例里，80%的数据库慢查询都是索引缺失或设计不当引起的。CC攻击时，一个全表扫描的烂SQL，其破坏力会成百上千倍地放大。 怎么看？ 打开你的数据库慢查询日志（MySQL的slow log，Pg的pg_stat_statements），盯着那些执行时间最长、扫描行数最多的语句。给 WHERE、ORDER BY、GROUP BY 的字段加索引，但也要避免索引过多影响写入。记住，在CC攻击下，一个高效的索引就是给数据库装上了涡轮增压。

• 连接池与慢查询熔断——设置“安全阀”

  1. 连接池调优： 检查你的数据库连接池（如HikariCP、Druid）配置。maximumPoolSize 设得太小，攻击一来连接瞬间耗尽，后面正常用户也连不上；设得太大，数据库进程可能被拖垮。根据数据库实际负载能力设置一个合理值，并设置合理的连接超时和空闲回收时间。
  2. 慢查询熔断/限流： 在应用层或数据库代理层（如ProxySQL），对执行时间超过阈值的SQL语句进行熔断。比如，同一个SQL模板在1分钟内超时5次，就暂时拒绝执行该类型的新请求，直接返回降级内容（如“服务繁忙”），而不是让它继续拖死数据库。这相当于给系统装了个保险丝，烧断了还能换，总比整个电路烧毁强。

• 读写分离与从库扛读——找个“替身” 这是架构层面的优化了。如果业务允许，把绝大部分的读请求（尤其是那些复杂的、耗时的报表类或列表查询）引流到数据库的只读从库上去。让主库专心处理写入和核心事务。 面对CC攻击，你可以把攻击流量引向从库集群，甚至专门准备一个配置稍低的从库作为“炮灰库”，用来承接这些恶意扫描请求，从而保护主库和核心从库的稳定。（当然，这里涉及到DNS调度或代理层路由，需要一定的架构基础。）

最后说点大实话

聊了这么多策略，其实核心思想就一个：面对CC攻击，你的防御必须是立体、有纵深的。 高防IP、WAF是城墙和护城河，但内存缓存和数据库优化，是你城堡内部的工事、粮道和应急预案。敌人万一冲进来了，你是依靠坚固的工事节节抵抗，还是因为内部混乱一触即溃？

我见过太多团队，每年在硬件防火墙和高防服务上花几十上百万，却舍不得投入两个人月去好好梳理一下核心业务的缓存策略和SQL语句。结果就是，攻击换一种姿势过来，钱白花了，业务还是挂。

所以，如果你的源站应用还没仔细做过这些“内功”优化，我建议你今晚就去看一眼慢查询日志和缓存命中率。 心里有点数，真遇到事儿的时候，才不至于手忙脚乱。

行了，不废话了，该检查代码的检查代码，该优化SQL的优化SQL去吧。真正的安稳，从来不是买来的，而是设计出来的。