我一直在阅读有关连接池的 SQLAlchemy 文档，而主题本身很简单；我认为这与您如何部署应用程序有很大关系（我在这里谈论的是 WSGI 应用程序）。
最近我开始使用Gunicorn。它有几种工人类型。目前我只使用同步工作人员：那些“一次处理一个请求”的工作人员。
所以在这种情况下，最好使用StaticPool，即每个工作人员有一个可重用的连接？或者 SQLAlchemy 即使在同步工作者的情况下也可以尝试建立多个连接？- 假设应用程序本身不使用线程。
问问题
1830 次
1 回答
3
完全有理由坚持使用默认值QueuePool：
QueuePool 只打开当时要求的尽可能多的连接。如果您的应用一次只使用一个连接，那么这就是您的应用将打开的唯一连接。
SQLAlchemy 本身永远不会打开超出您告诉它的其他连接（任何需要数据库访问的东西基本上都将使用单个连接来访问数据库。比如 create_all() 或 Session.query().whatever。它只使用一个连接一次。）。
如果你的应用碰巧有某种东西会一次产生多个连接，例如一次使用两个 Session 对象，或者当你仍在从另一个引擎获取结果时调用 engine.execute()。 execute()，QueuePool 将毫无问题地建立第二个连接。而 StaticPool 将使用相同的连接，然后您会遇到问题。
如果您真的想确保您的应用程序每个进程只使用一个连接，您可以查看 AssertionPool - 虽然这更像是一个调试/测试池，但不一定是我们大规模使用的一个。或者用pool_size=1和max_overflow=0设置QueuePool，如果你试图在一个线程中同时打开两个连接，基本上会导致死锁....
于 2014-03-08T01:05:27.977 回答