2、高并发挑战：审计系统的瓶颈分析、并发模型与资源竞争
讲真，很多团队做审计系统，第一版能跑通就急着上线了。等日均日志量从几万涨到几百万，接口响应时间从 50ms 飙到 3s，才开始喊“扛不住了”。我接手过一个金融审计平台，上线三个月，每天凌晨批处理直接把数据库拖死，触发了 OOM Killer……嗯，那次教训挺深刻的。
这一章，我们就聊三个核心问题：瓶颈到底在哪里？用什么并发模型？资源竞争怎么解？
2.1 瓶颈分析：哪些环节最脆弱？
审计接口的典型流程很简单：接收请求 → 解析参数 → 校验合规 → 写入审计日志 → 返回结果。但我告诉你，每一环都可能成为瓶颈。
| 环节 | 常见瓶颈 | 影响程度 | 我踩过的坑 |
|---|---|---|---|
| 请求接入 | 线程池满、连接耗尽 | 高 | 曾经用无界队列，直接堆满内存 |
| 参数解析 | JSON序列化/反序列化 | 中 | 大报文解析耗时超 200ms |
| 合规校验 | 规则引擎、外部依赖 | 高 | 调第三方黑名单接口超时连锁崩溃 |
| 日志写入 | DB连接池、磁盘IO | 极高 | 单条插入瓶颈，QPS上不去 |
| 返回响应 | 网络带宽、序列化 | 低 | 基本不用太操心 |
2.2 并发模型：选对模型，少走弯路
高并发场景下，并发模型直接决定系统能扛多少路。常见的三种模型：多线程模型、异步事件驱动、协程模型。你想想看，它们本质是在抢 CPU 和 IO 的时间片。
| 模型 | 核心机制 | 适合场景 | 典型问题 |
|---|---|---|---|
| 多线程 | 每请求一线程 | 计算密集型、短IO | 线程切换开销大，内存占用高 |
| 异步事件 | Select/Epoll + 回调 | IO密集型、长连接 | 回调地狱，调试困难 |
| 协程 | 用户态调度 | 高并发、混合型 | 栈溢出风险，生态不成熟 |
我个人习惯，审计系统首选异步 + 协程的混合模型。为什么？审计的核心操作是写日志，这是典型的 IO 密集型。你用多线程，光上下文切换就能吃掉 30% 的 CPU。我用 Go 的 goroutine 或者 Java 的虚线程，单机就能扛万级并发。
CompletableFuture + 自定义线程池隔离。把校验、写入拆成独立异步任务，配合 CountDownLatch 聚合结果。别问我怎么知道的——改完之后，接口 TP99 从 1.2s 降到了 280ms。
2.3 资源竞争：锁、池、队列
并发一上来，资源竞争就不可避免。常见的竞争场景：数据库连接池争抢、共享变量锁竞争、内存队列溢出。我见过最夸张的场景：一个审计服务用了 200 个线程，连接池只有 10 个，结果 190 个线程都在等连接，CPU 空转 80%。
2.3.1 数据库连接池
审计写入需要数据库连接。连接池太多浪费资源，太少排队严重。怎么配？经验公式：最大连接数 = (CPU核数 * 2) + 异步连接数。但要注意，如果你的审计写入走批量插入，连接占用时间会缩短，池子可以适当缩紧。
// 优化前：单条插入，连接占用长
INSERT INTO audit_log (user_id, action, time) VALUES (?, ?, ?);
// 优化后：批量插入，连接复用率高
INSERT INTO audit_log (user_id, action, time) VALUES
(?, ?, ?), (?, ?, ?), (?, ?, ?);
2.3.2 锁竞争
很多审计系统需要保证日志顺序号唯一。有人用 synchronized 或 ReentrantLock 生成序号，结果 QPS 一高，锁成了瓶颈。我个人倾向用无锁方案：比如 AtomicLong 或者分布式 ID 生成器。实在要加锁，用 StampedLock 乐观读，减少写锁冲突。
2.3.3 内存队列
审计日志先写内存队列，再批量刷库。这是最常见的削峰手段。但队列本身也会成为竞争点。我建议使用无锁环形队列（Disruptor）或者单生产者多消费者模式。不要把队列当作万能药——曾经有团队用 LinkedBlockingQueue 无界队列，日志积压几百万条，直接 OOM。
2.4 本章核心逻辑图
我把审计系统的瓶颈点、并发模型和资源竞争的核心关系画成一张流程图，方便你一目了然。