晚八点直播课叠加点名签到导致连接池先报警，根源在于短时间内大量并发请求耗尽数据库连接数，核心应对方案是扩容连接池、优化查询、引入缓存并实施限流。
我清楚记得那天晚上8点整，监控屏上一片红，连接池报警像炸了锅，点名签到和直播课同时开启，几千个学生一起操作，我们的应用服务器瞬间没了响应，事后复盘发现，系统本身扛得住，但连接池成了最薄弱的环节，下面我把排查过程、优化方案和踩过的坑全部分享出来,帮同样遇到连接池报警的团队少走弯路。
晚八点直播课点名签到连接池报警原因排查
这个时间点出问题，不是巧合，晚八点是直播课的高峰期，大部分学生同时上线，点名签到功能又需要实时写入数据库，双重压力下连接池第一个报警，行业共识认为，连接池耗尽通常由三个因素叠加造成：请求量短期暴增、单个请求占用连接时间过长、连接池大小配置不合理。
点名签到功能如何压垮连接池
点名签到看似简单，但每个学生点击后，系统要先查数据库核对课次信息，再写入签到记录，最后更新状态，如果班级人数上千，这些操作会在同一秒内并发到达，更隐蔽的是，很多签到逻辑里还包含了异步任务，比如发送通知、记录日志，这些任务如果也占用数据库连接，就会加剧资源竞争。
连接池报警的典型特征
- 报警时间固定在整点前后，与直播课开始时间吻合。
- 错误日志中频繁出现 `ConnectionPoolTimeoutException` 或 `Cannot acquire connection`。
- 监控曲线显示活跃连接数瞬间打满，等待队列积压。
- 数据库CPU和内存无明显异常，说明瓶颈不在数据库本身，而是应用层连接池分配不足。
排查步骤与实操命令
1. 检查连接池配
置：在应用配置文件中确认 `maxActive`（最大连接数）和 `maxWait`（最大等待时间）的值，比如我们当时用的是HikariCP，默认 `maximumPoolSize` 只有10，远远不够。
2. 抓取连接池快照：通过 JMX 或接口获取当前连接使用情况，`jvisualvm` 连接后查看 `HikariPoolMXBean`，实时看到活跃连接数。
3. 分析慢查询：开启 MySQL 慢查询日志，定位是否有点名签到相关的SQL执行时间过长，命令：`set global slow_query_log=1; set global long_query_time=1;`
4. 模拟并发测试：用jmeter或locust编写脚本，模拟晚八点场景，验证连接池是否在预期并发下锁定。
直播课连接池优化方案对比：扩容、缓存、限流
这是整个问题的核心解决路径，我经历了三种主流方案的对比实践，各自优劣明显。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 扩容连接池 | 实施简单，立即见效 | 治标不治本，增加数据库压力 | 连接池初始值过小 |
| 引入缓存 | 减少数据库读写，降低连接数 | 增加运维复杂度，需处理缓存一致 | 点名签到可接受短暂延迟 |
| 实施限流 | 保护后端资源，防止雪崩 | 部分请求被拒绝，影响体验 | 流量峰值远超系统容量 |
扩容连接池的具体操作
大多数框架默认连接池值偏保守，建议根据业务峰值调整，公式为：`峰值并发请求数 / (单个请求平均耗时 连接复用因子)`，我们当时把HikariCP的 `maximumPoolSize` 从10逐步调到50，连接池报警立刻缓解，但要注意，连接数不是越大越好，超过数据库可用连接数会导致数据库拒绝连接，调整后需观察数据库连接数上限 `max_connections`，并同步加大。
缓存方案实践
点名签到数据允许短暂延迟，所以非常适合用Redis缓存，我们在签到逻辑中先写Redis，再异步批量写入MySQL，步骤：
- 哈希结构存储签到记录，key为课次ID，field为学生ID，value为签到时间。
- 设置定时任务，每5秒将新数据批量写入数据库。
- 读取时先查Redis，未命中再查数据库并回填缓存。
这样大部分请求不占用数据库连接，连接池压力大幅下降。
限流策略部署
缓存不能解决所有问题，比如直播课开始瞬间的请求洪峰，我们采用滑动窗口限流，基于Redis的 `zset` 实现，每秒允许通过请求数根据历史峰值计算，核心代码逻辑：
```java
// 滑动窗口限流
String key = "rate_limit:signin:" + lessonId;
long now = System.currentTimeMillis();
long window = 1000L; // 1秒窗口
long threshold = 200; // 每秒允许200个请求
// 移除窗口外数据
jedis.zremrangeByScore(key, 0, now - window);
// 统计当前请求数
long count = jedis.zcard(key);
if (count < threshold) {
jedis.zadd(key, now, String.valueOf(now));
// 允许请求
} else {
// 返回限流提示
}
```
限流的同时，配合降级，超限的签到请求进入等待队列，过几秒后重试。
连接池泄漏检测
优化过程中我还踩过泄漏的坑，有些请求获取连接后忘记释放，时间一长连接池慢慢被耗尽，排查方法：监控连接池的 `active` 和 `idle` 数量，如果活跃连接数持续增长不回落，说明有泄漏，开启HikariCP的 `leakDetectionThreshold` 参数，设置30000毫秒，当连接占用超过阈值时，日志会打印堆栈信息，定位到具体代码行。
如何预防晚八点连接池报警
防患未然比事后补救更重要，我总结了三条预防措施，已经融入日常运维。
压力测试常态化
每次直播课功能上线前，必须用与线上一致的并发模型做压测，重点关注连接池活跃数、等待队列长度、数据库QPS三项指标，压测脚本中要包含点名签到和其他高频操作，模拟真实用户行为。
配置可动态调整
连接池参数不能写死，要支持运行时修改，我们通过配置中心（如Apollo）管理 `maximumPoolSize` 和 `maxWait`，在直播课开始前10分钟自动调整到高峰值，结束后恢复，这样避免了固定配置带来的资源浪费。
降级预案自动化
一旦连接池报警触发，自动执行降级工具：关闭非核心功能（如签到后发送通知），提高缓存命中率，甚至将签到模式改为“先签后入库”的异步模式，这些逻辑通过开关和配置中心即可远程控制。
晚八点直播课点名签到连接池报警常见问题
连接池报警一定是连接数不够吗？
不一定，如果连接池大小合理，但每次请求耗时很长，依然会报警，优先排查是否存在慢查询或锁等待，比如点名签到中如果使用了 `select ... for update`，会导致其他请求排队，连接释放变慢，建议先分析慢查询日志，再决定是否扩容连接池。
扩容连接池后为什么数据库还是报警？
单方面扩大应用连接池，数据库端如果没有相应增加 `max_connections`，数据库就会拒绝连接，数据库CPU和内存也可能成为瓶颈，需要同时监控数据库端的连接数负荷，并考虑读写分离，把点名签到写入放在从库上，降低主库压力。
点名签到能不能完全不用数据库？
完全不用数据库不现实，因为签到数据需要持久化，但可以把数据库操作后置，前端先用客户端缓存或Redis临时存储，等到用户离开高峰时段再批量写入，这样用户在晚八点操作时，感受不到数据库延迟，连接池压力也转移到异步任务中。