AsyncAppender 队列打满时 neverBlock 二选一：「丢关键审计日志」vs「阻塞业务线程引发 5xx」，有没有第三方案与可复现的取舍判据？

【背景】 5 年 SRE，服务栈：Spring Boot 3.2 + JDK 17 + Logback 1.4.14，K8s 滚动发布，每副本 4C8G，应用日志落云盘 ESSD PL1（标称 3000 IOPS / 125MB/s）。日志链路是标准 AsyncAppender 包 RollingFileAppender：<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"><queueSize>8192</queueSize><discardingThreshold>0</discardingThreshold><neverBlock>false</neverBlock>。平时 P99 稳定在 30ms 左右，日志量约 200 行/s/副本。

【现象】 最近两次发布窗口各踩中一次「日志风暴」：新版本上线后一个边界 case 在异常分支里每请求打 5~8 行 WARN（含完整入参 JSON），10 分钟内单副本日志量冲到 ~20000 行/s，写盘 IOPS 直接顶到 PL1 上限。随后发生的事很魔幻：

• 业务线程大量阻塞在 AsyncAppender 的 BlockingArrayBlockingQueue.put() 上（neverBlock=false），jstack 里 Tomcat 工作线程一片 WAITING on AsyncAppender；
• P99 从 30ms 飙到 1.8s，网关开始回 504；
• 更糟的是网关超时重试又带来更多请求、更多异常日志，形成正反馈——日志把服务拖死，服务越死日志越多。

【已尝试的排查与结果】

1. neverBlock=true：5xx 确实没了，但压测复现风暴时 8192 队列 3 秒打满，之后全部日志直接丢——其中包含支付流水号级别的审计日志，合规不答应，等于把「故障」换成了「事故」；
2. queueSize 拉到 65536 + discardingThreshold=0：队列内存吃掉约 400MB/副本，风暴时长被拉长到 ~25s 才吐完，期间业务线程照样排队阻塞，只是「阻塞时间变长了」，没治本；
3. 降级刷盘：给 RollingFileAppender 换 immediateFlush=false + 加大行缓冲，IOPS 压力降到 ~60%，但队列还是会在风暴峰值打满，治标不治本；
4. arthas trace 量化：稳态时每条请求路径日志开销 ~1.2ms（约 15 次 log.info/warn），风暴时单条阻塞 200ms~2s 不等，确认瓶颈在 appender 刷盘 + 队列，不在 logger 锁。

【期望得到的答案形态】

1. 一个可复现的第三方案：既不在风暴时阻塞业务线程、又不无声丢掉关键路径（审计/对账）日志的工程做法——比如双 Appender 分级（关键日志走同步小队列、普通日志走异步大队列 neverBlock）、按 MDC/Logger 名采样降级、或者把日志走 sidecar/filebeat 让 appender 只写本地 socket 等，请给出具体配置与容量计算；
2. 一套取舍判据：什么量级/什么日志级别允许 neverBlock 丢、什么必须保？queueSize 和 discardingThreshold 有没有基于「写盘吞吐 × 风暴峰值倍数」的可计算公式，而不是拍脑袋？
3. 一个防正反馈的护栏：异常分支日志风暴（同异常重复打点）在代码层/框架层怎么限流，比如按异常指纹采样，有没有开源实现或最小代码示例？

站内已读过相关经验：《一条 log.info 把 P99 从 30ms 拖到 2.3 秒：同步日志刷盘的锁竞争与 AsyncAppender 调参》(id=888) 和《Log4j2 异步日志的背压陷阱：ringBuffer 打满后静默丢日志的排查与三档调参》(id=1036)，但「neverBlock 二选一的合规级取舍 + 风暴正反馈护栏」这个组合还没看到，故提问。