SQLAlchemy中asyncpg连接泄漏问题分析与解决方案

问题背景

在使用SQLAlchemy与asyncpg驱动结合FastAPI、Starlette等框架时，当通过anyio任务组取消包含数据库连接操作的HTTP处理程序任务时，会出现数据库连接泄漏的问题。具体表现为：虽然SQLAlchemy和asyncpg认为连接已关闭，但实际上PostgreSQL服务器端仍保持连接处于空闲状态。

问题复现

通过以下代码可以稳定复现该问题：

import asyncio
import asyncpg
import anyio
from sqlalchemy.ext.asyncio import async_sessionmaker, create_async_engine
from sqlalchemy.sql import text

# 配置数据库连接
engine = create_async_engine("postgresql+asyncpg://postgres:postgres@localhost/postgres", 
                           pool_size=1, max_overflow=0, echo_pool="debug")
async_session = async_sessionmaker(engine, expire_on_commit=False)

async def querier():
    async with async_session() as session, session.begin():
        res = await session.execute(text("select 1"))
        print([row for row in res])
        await asyncio.sleep(10)  # 模拟长时间异步操作

async def main():
    while True:
        t = asyncio.create_task(anyio.create_task_group().start_soon(querier))
        asyncio.create_task(asyncio.sleep(1)).add_done_callback(lambda _: t.cancel())
        try:
            await t
        except asyncio.CancelledError:
            print("任务被取消")

问题分析

当使用anyio任务组取消包含数据库操作的任务时，会出现以下流程：

1. 任务被取消时，SQLAlchemy会尝试使连接失效并硬关闭
2. 但在关闭过程中，asyncpg的连接关闭操作被CancelledError中断
3. 导致SQLAlchemy认为连接已关闭，但实际上PostgreSQL服务器端连接仍然存活

相比之下，使用原生asyncio任务组时，连接能够正常回滚并返回连接池，不会出现泄漏。

技术原理

问题的核心在于asyncpg的连接关闭操作没有被正确保护，当遇到CancelledError时会中断关闭过程。SQLAlchemy的连接池管理机制在这种情况下无法确保连接被完全关闭。

解决方案

SQLAlchemy团队通过以下方式修复了该问题：

1. 在asyncpg的连接终止(terminate)操作中添加shield保护
2. 确保连接关闭操作不会被CancelledError中断
3. 保证连接能够被完全关闭，避免泄漏

最佳实践

为避免类似问题，建议：

1. 对于关键资源操作（如数据库连接）使用shield保护
2. 在取消任务时，确保所有资源都能被正确释放
3. 监控数据库连接数，及时发现可能的泄漏
4. 考虑使用原生asyncio任务组替代anyio任务组（如果适用）

总结

SQLAlchemy与asyncpg的结合在异步环境中表现优异，但在任务取消等边界条件下可能出现连接泄漏问题。通过理解底层机制和采用适当的防护措施，可以确保数据库连接的可靠管理。该问题的修复体现了SQLAlchemy团队对异步编程边界条件的深入理解和处理能力。