如何让OpenStack Nova的Worker共享统一数据库连接池？

针对你提出的Nova Worker共享统一连接池的需求，可行，主要有两种实践方向：改造Nova进程模型实现进程内连接池共享，或引入外部数据库连接池代理，以下是具体细节：

核心背景回顾 #

Nova的数据库连接由Oslo DB管理，底层基于SqlAlchemy，默认每个Worker进程会独立初始化专属的连接池，max_pool_size（或api_max_pool_size）控制持久连接数，max_overflow控制瞬时连接数。大规模部署下，多实例+多Worker的架构会导致大量闲置连接浪费，挤占其他组件（如nova-conductor）的连接资源。

你的场景对比：

当前专属连接池场景 #

# nova-api实例数 = 10
# 每个实例的Worker数 = 6
max_pool_size = 5
api_max_pool_size = 5

# 稳态下占用的数据库连接数 = 10 * 6 * (5+5) = 600
假设数据库最大允许1000并发连接，600个闲置连接会严重影响整个系统

理想共享连接池场景 #

# nova-api实例数 = 10
# 每个实例的Worker数 = 6
max_pool_size = 5
api_max_pool_size = 5

# 稳态下占用的数据库连接数 = 10 * (5+5) = 100
（Worker共享同一连接池，无需乘以Worker数量）

可行实现方案 #

1. 改造Nova Worker为单进程多线程模式 #

Nova默认采用多进程Worker（如gunicorn的fork模式），每个进程独立维护连接池。若改为单进程多线程Worker，则同一进程内的所有线程可共享同一个SqlAlchemy连接池，直接实现Worker级别的连接复用。

操作方式：

• 调整nova-api的启动配置，将gunicorn的worker_class设置为threaded（或eventlet协程模式，协程也共享进程内连接池）。
• 配合Oslo DB的连接池参数，确保max_pool_size和max_overflow是针对整个进程而非单个Worker。

优缺点：

• 优点：无需额外组件，仅调整配置即可实现，连接利用率提升明显。
• 缺点：受CPython GIL限制，CPU密集型请求的性能会下降；部分需要进程隔离的复杂业务场景可能不适用。

2. 引入外部数据库连接池代理 #

这是大规模OpenStack部署中更常用的方案，通过在Nova集群与数据库之间部署独立的连接池代理，统一管理所有Nova实例的连接请求，实现跨Worker、跨实例的连接复用。

常用代理工具：

• PostgreSQL：PgBouncer
• MySQL：ProxySQL、MaxScale

操作方式：

• 部署代理组件并配置全局连接池参数（如最大连接数、闲置超时、连接复用策略）。
• 修改Nova的数据库连接配置，将连接地址指向代理而非直接指向数据库。
• 调整Nova自身的连接池参数（如降低max_pool_size），让Worker优先向代理请求连接。

优缺点：

• 优点：完全兼容现有Nova多进程架构，无需修改代码；对OpenStack所有组件透明，可统一管控整个集群的数据库连接，避免闲置连接浪费。
• 缺点：需额外部署和维护代理组件，增加架构复杂度；需合理配置代理与Nova的连接池参数，避免出现连接阻塞或代理瓶颈。

关键注意事项 #

• SqlAlchemy的Engine和连接池本身不是进程安全的，不要尝试直接在多进程Worker之间共享连接池对象，会导致并发冲突和数据异常。
• 外部代理方案需确保代理的高可用性（如部署集群），避免成为单点故障；同时要监控代理的连接状态，及时调整池参数。

内容的提问来源于stack exchange，提问作者Yanchi De Zhang