如何优化Python Flask处理高频写请求的响应延迟？-Python教程-PHP中文网

高频写请求延迟主因是同步阻塞、db事务排队及副动作拖慢，须“能异步的异步、不能异步的削峰、不能削峰的拆开”；async视图对db写无效，因commit等仍是cpu/锁密集型；副动作需剥离至celery/rq；db层应绕过orm、批量写、调优连接池；http层需流式解析、禁用美化输出；gunicorn宜用gevent/eventlet；关键在厘清同步边界。

如何优化python flask处理高频写请求的响应延迟？

高频写请求的延迟根本不在 Flask 本身，而在同步阻塞、数据库事务排队、日志/通知等副动作拖慢主流程。直接上结论：写操作必须“能异步的异步，不能异步的削峰，不能削峰的拆开”，否则加再多 worker 也卡在锁和 I/O 上。

为什么 `async` 视图对写接口经常没用？

Flask 的 async 视图只在等待 I/O（如 HTTP 调用、Redis 命令）时释放事件循环；但绝大多数写请求瓶颈是同步数据库 commit()、文件写入或 ORM 模型校验——这些仍是 CPU/锁密集型，async 不起作用。

PostgreSQL 的 INSERT ... RETURNING 或 MySQL 的 LAST_INSERT_ID() 都要等事务落盘，async 不跳过磁盘写
SQLAlchemy 默认开启 autoflush + autocommit 关闭，db.session.add() 后不 commit() 就返回，数据其实没持久化，用户看到“成功”但实际丢了
如果你用的是 SQLite，它默认 WAL 模式都不开，所有写请求串行排队，async 更是白搭

把耗时副动作从主请求中剥离

写成功 ≠ 所有事做完。发邮件、推消息、生成报表、更新搜索索引……这些不该堵住 HTTP 响应。

Python 3.14.2

Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。

下载

用 Celery 或 RQ 异步调度：写入 DB 后立刻 celery.send_task('tasks.send_notification', args=[user_id])
避免在视图里调 requests.post()：哪怕超时设成 0.5 秒，100 QPS 就意味着平均 50 个连接在等外部服务，直接拖垮整个进程
日志别用 logging.info() 写大对象：序列化 request.json 再格式化输出，比写 DB 还慢；改用结构化日志 + 异步发送到 Loki/ELK

数据库写入层必须做三件事

不是加索引就完事，写路径的优化逻辑和读完全不同。

关闭不必要的 ORM 层开销：对高频写接口，直接用 db.session.execute(text("INSERT INTO ...")) 绕过模型实例化
批量写代替单条：前端聚合事件（如“用户连续点击 5 次”），后端用 executemany() 或 PostgreSQL UNNEST() 一次插入多行
确认连接池配置：SQLAlchemy 的 pool_size 和 max_overflow 必须大于你的 Gunicorn worker 数 × 平均并发写请求数，否则线程全卡在 getconn()

别忽略 HTTP 层的隐形延迟

你以为瓶颈在业务逻辑，其实可能是 Flask 自己的解析或 WSGI 封装在拖后腿。

request.get_json() 默认强制解析整个 body：如果上传的是 2MB JSON，Flask 就得先读完再解码，期间线程完全阻塞；改用 request.stream 流式处理或限制 MAX_CONTENT_LENGTH
禁用 Flask 的 JSONIFY_PRETTYPRINT_REGULAR：它会让每个响应多花几毫秒做缩进，高频写接口返回 {'ok': true} 就够了
Gunicorn 别用 sync 模式扛写流量：至少切到 gevent 或 eventlet，否则每个写请求独占一个 worker，连接数一上来就排队