Flask · 188

数据库连接健康检查

数据库的健康检查看起来就是 select 1,但它走哪个连接池、数据库卡住时多久放弃,都会改变探针的含义。这篇用真实的 PostgreSQL 和 gunicorn 逐项验证(健康检查接口的基本形态见第 179 篇,连接重连见第 100 篇)。

2497 → 10 ms

业务池被占满时,就绪检查共用池 vs 独立小池的耗时

≥ 2 s

设 connect_timeout=1 实际等待的时间(libpq 最小值)

512 ms

statement_timeout=500ms 时慢查询的探针耗时

← 上一篇 Secret Key 轮换

select 1

实测 · 本机执行输出

  数据库正常:200 ready(8 ms)
  数据库停掉:503 OperationalError(1 ms)
  数据库重新启动后:200 ready(13 ms)

上一篇:Secret Key 轮换;下一篇:容器信号处理。

数据库是自己起的 PostgreSQL 实例(非默认端口);「卡住」的数据库用一个接受连接但不回应的本地端口模拟。

连接池被占满

实测 · 本机执行输出

  就绪检查走业务连接池(/ready-shared):HTTP 200 ready,2497 ms
  就绪检查用独立的 1 连接小池(/ready-own):HTTP 200 ready,10 ms

数据库卡住

实测 · 本机执行输出

  连不上,不设 connect_timeout        → 探针客户端 6 秒后放弃(TimeoutError)
  连不上,connect_timeout=1         → HTTP 503 OperationalError,2002 ms
  查询很慢,不设 statement_timeout     → HTTP 200 ready,3013 ms
  查询很慢,statement_timeout=500ms  → HTTP 503 OperationalError,512 ms

分步演示

Flask 数据库连接健康检查

本步的对象

本文用到的工具与边界

本机 macOS 27 arm64 / Python 3.14.7 / Flask 3.1.3 / Werkzeug 3.1.9 / Jinja2 3.1.6 / SQLAlchemy 2.1.1 / gunicorn 26.2.0(都装在自己的虚拟环境里);大多数实验用 Flask 的 test_client(直接调用 WSGI 应用,不经过网络),需要真实 HTTP 时另起 gunicorn 或开发服务器(端口 9600 以上,本机 127.0.0.1);计时用 time.perf_counter,数字每次运行会有小幅抖动。PostgreSQL(自己的实例)、Flask-SQLAlchemy、gunicorn(gthread)
没有验证:pool_timeout 到期时的 TimeoutError(本次等待短于它)、主从切换与只读副本的健康检查、pgbouncer 等连接代理、检查频率对数据库的负载、云厂商托管数据库的故障表现;「卡住」的数据库只用一个接受连接但不回应的本地端口模拟

下一篇 · FLASK 189

容器信号处理