首先得说：你提到的"日志轰炸"这个表述非常准确——就是同一内容（包括消息模板和参数）的日志在短时间内疯狂重复输出，比如DoS攻击触发的missing token警告，动辄十万条起步，不仅撑爆日志文件占用存储，还严重干扰正常日志的排查效率。

下面是几个经过实践验证的解决方案，按优先级排序：

1. 从日志输出层做去重限流 #

这是最直接的拦截手段，核心思路是对相同日志特征做计数，达到阈值后暂停重复输出，只保留汇总信息。

• Logback 用户：可以自定义TurboFilter来实现。比如生成每条日志的哈希值（基于日志消息+参数），用一个本地缓存（比如Guava Cache）维护计数器，当同一哈希的日志超过设定阈值（比如10次），就暂时过滤，每隔固定时间（比如1分钟）输出一条汇总日志："missing token" 已重复12345次，暂停重复输出。
• Log4j2 用户：直接用官方自带的BurstFilter，配置起来非常简单，比如：

<BurstFilter level="WARN" rate="5" maxBurst="10" />

这个配置会限制WARN级别日志每秒最多输出5条，突发峰值最多10条，超过的直接被过滤，完美应对短时间的日志轰炸。

2. 从应用层拦截恶意请求 #

日志轰炸大多来自恶意请求（比如DoS），从源头减少这类请求，就能从根本上解决问题：

• 给接口加限流策略：比如用Guava的RateLimiter给单个IP设置请求上限，或者在网关层（比如Nginx、Spring Cloud Gateway）做全局限流，超过阈值的直接拒绝，不进入应用层，自然不会产生日志。
• 动态调整日志级别：当检测到同一IP短时间内触发多次未授权访问时，把这类日志从WARN降级到DEBUG甚至TRACE，平时不输出，只有需要排查时再临时开启。

3. 配置日志滚动与自动清理 #

即使有前面的拦截措施，还是可能产生大量日志，所以要配合归档清理策略：

• 按大小/时间滚动日志：比如用Logback的RollingFileAppender，设置日志文件达到100MB就自动归档，或者每天生成一个新的日志文件。
• 自动清理旧日志：配置日志框架自动删除7天前的旧日志，或者把归档的日志压缩成zip格式，大幅节省存储空间。

4. 事后聚合重复日志（兜底方案） #

如果已经产生了大量重复日志，或者需要保留记录但不想占用太多空间，可以用日志分析工具做事后聚合：

• 比如在日志分析平台中，用聚合查询把相同的日志条目合并，只展示计数和时间范围，既保留了关键信息，又避免了日志文件体积过大。

最后补充一句：如果你的应用是分布式部署，建议用Redis来统一计数不同节点的相同日志，避免每个节点各自输出汇总信息，造成重复的汇总日志。

内容的提问来源于stack exchange，提问作者AlikElzin-kilaka