Flask+Waitress实时数据分析任务队列阻塞及死锁问题求助

问题根源 #

1. 单线程模式下，Waitress同一时间只能处理一个请求，而数据库查询（尤其是select *全表读取）属于IO密集型操作，会阻塞整个服务，导致后续请求排队堆积。
2. 直接将线程数增至4后触发死锁，大概率是数据库连接管理不当：每个请求都新建独立连接，多线程下连接数暴增，或连接未正确释放导致连接泄漏，进而引发数据库端锁冲突；也可能是全表查询本身会锁表，多线程并发查询时加剧了锁竞争。

优先优化方案（低成本见效快） #

1. 优化数据库查询

• 避免使用select *，只查询AI模型必需的字段，减少数据传输量和查询耗时。
• 给查询涉及的字段添加索引，大幅提升查询效率，降低数据库锁表概率。
• 示例优化后的SQL：

  select required_col1, required_col2 from mydatabase.Table where [过滤条件]
  

2. 用连接池管理数据库连接

不要每个请求都新建/关闭连接，复用连接可避免频繁创建连接的开销，同时控制最大连接数防止数据库资源耗尽：

# 全局初始化连接池（仅执行一次）
import pyodbc
pyodbc.pooling = True

# 接口中获取连接
@app.route("/api/prediction", methods=["GET","POST"])
def prediction():
    # 从连接池获取连接，无需手动关闭，断开时自动归还池
    with pyodbc.connect("Driver={ODBC Driver 17 for SQL Server};SERVER=myserver;database=mydatabase;UID=sa;password=providedpassword;") as conn:
        mydata = pd.read_sql("select required_col1, required_col2 from mydatabase.Table", conn)
        # 数据清洗与后续逻辑

3. 合理调整Waitress线程数

不要直接跳到4线程，先从2线程开始测试，同时配合连接池将最大连接数设为线程数的1.5倍左右（比如线程数2，连接池最大连接数3），观察死锁是否消失。死锁大概率是连接过载或查询锁表导致，优化后再逐步调整线程数。

进阶方案（优化后仍无法满足实时性时） #

如果数据库查询和AI计算确实耗时极长，可考虑以下方案：

1. 多进程部署

用Waitress的多进程模式，或替换为Gunicorn+多进程，每个进程拥有独立的连接池，避免线程间的资源竞争：

# Waitress多进程配置示例
serve(app, host='127.0.0.1', port=50100, threads=2, processes=2)

2. 异步任务队列

将耗时的数据库查询、AI计算放到后台任务队列（如Celery+Redis），API仅负责接收请求并返回任务ID，客户端通过轮询获取结果，彻底避免阻塞主线程：

• 步骤：
  1. API接收请求，生成唯一任务ID，将计算参数发送至任务队列。
  2. Celery Worker从队列取出任务，执行数据库查询、AI计算。
  3. 客户端通过任务ID查询计算结果。

总结 #

优先从数据库查询优化、连接池管理入手，这是解决问题最直接、成本最低的方式。若优化后仍无法满足实时性需求，再考虑多进程或异步任务队列方案。直接增加线程数导致死锁的核心原因是连接管理或查询本身的问题，需先解决这些再调整线程配置。

内容的提问来源于stack exchange，提问作者Amanda Choy Siew Wen