Rbatis项目中FastPool连接池泄漏问题的分析与解决

2025-07-02 01:24:52作者：薛曦旖Francesca

问题背景

在分布式系统开发中，数据库连接池是至关重要的组件之一。Rbatis项目中的FastPool连接池在高并发场景下被发现存在连接泄漏问题。具体表现为：在持续高并发压力测试后，连接池中的连接数量会逐渐减少，最终导致可用连接不足，影响系统整体性能。

问题现象重现

开发人员通过以下方式重现了该问题：

使用APIPost工具模拟100个并发请求
每个并发执行1000轮次数据库操作
监控连接池状态变化

初始测试结果显示：

最大打开连接数：12
当前连接数：12
空闲连接：9
使用中连接：3

继续执行相同压力测试后，状态变为：

最大打开连接数：12
当前连接数：12
空闲连接：7
使用中连接：5

同时，通过MySQL的show full processlist命令发现实际只有7个活跃连接，表明存在连接泄漏情况。

问题根因分析

经过深入排查，发现问题主要出现在以下几个方面：

连接回收机制不完善：在高并发场景下，FastPool库在处理"正在连接中"的数据库连接时存在遗漏，导致部分连接未能正确回收。
异常处理不足：当客户端异常终止请求（如测试工具超时强制中断）时，连接未能通过ConnectionBox的Drop特性方法进行回收，而是直接被丢弃。
连接计数不一致：连接池的状态统计（connections计数）与实际物理连接数存在偏差，导致后续无法正确创建新连接来补充丢失的连接。

解决方案演进

开发团队通过多次迭代逐步完善了解决方案：

第一阶段修复（fast_pool v0.2.2）

初步修复了高并发场景下连接处理的遗漏问题。主要改进包括：

完善连接状态跟踪机制
优化连接回收逻辑

第二阶段优化（fast_pool v0.3.2）

进一步解决了以下问题：

确保异常终止时连接能够正确回收

改进连接计数机制，动态计算实际连接数：

let connections = self.idle_send.len() as u64 
                + self.in_use.load(Ordering::SeqCst) 
                + self.connecting.load(Ordering::SeqCst);

状态统计更加准确反映实际连接情况

最终完善（fast_pool v0.3.3）

引入"connecting"（连接中）和"checking"（检查中）状态
确保所有状态统计之和与实际连接数一致
增强连接健康检查机制，自动丢弃无效连接

技术实现细节

连接池的核心改进集中在ConnectionBox的Drop特性实现上：

impl<M: Manager> Drop for ConnectionBox<M> {
    fn drop(&mut self) {
        self.in_use.fetch_sub(1, Ordering::Release);
        if let Some(v) = self.inner.take() {
            let max_open = self.max_open.load(Ordering::Relaxed);
            if self.sender.len() as u64 + self.in_use.load(Ordering::Acquire) < max_open {
                _ = self.sender.send(v);
            } else {
                self.connections.fetch_sub(1, Ordering::Release);
            }
        }
    }
}