MySQL - 持久连接与连接池答案

【问题标题】：MySQL - Persistent connection vs connection poolingMySQL - 持久连接与连接池
【发布时间】：2012-03-16 11:09:03
【问题描述】：

为了避免每次需要向 MySQL 发起查询时建立新连接的开销，有两个可用选项：

所以，如果我有一个多线程服务器应用程序，预计每秒处理数千个请求，并且每个线程都需要对数据库进行查询，那么有什么更好的选择？

据我了解，使用持久连接，我的应用程序中的所有线程都将尝试使用与数据库的相同持久连接，因为它们都使用相同的连接。所以它是一个跨多个应用程序线程共享的连接——因此请求将很快在数据库端阻塞。

如果我使用连接池机制，我将让所有应用程序线程共享一个连接池。因此阻塞请求的可能性较小。但是，对于连接池，应用程序线程应该等待从池中获取连接，还是应该以循环方式向池中的连接发送请求，并让队列（如果有）发生在数据库上？

【问题讨论】：

【解决方案1】：

拥有持久连接并不意味着所有线程都使用相同的连接。它只是“说”您保持连接打开（与每次需要连接时都打开连接相反）。打开连接是一项代价高昂的操作，因此 - 通常 - 您会尽量避免打开连接过于频繁。

这就是多线程应用程序经常使用连接池的原因。池负责打开和关闭连接，每个需要连接的线程都从池中请求一个。重要的是要注意线程尽快将连接返回到池中，以便另一个线程可以使用它。

如果您的应用程序只有几个需要连接的长时间运行的线程，您还可以为每个线程打开一个连接并保持打开状态。

仅使用一个连接（如您所描述的）等于最大大小为 1 的连接池。这迟早会成为您的瓶颈，因为所有线程都必须等待连接。这可能是序列化数据库操作的一个选项（按特定顺序执行它们），尽管有更好的选项来确保序列化。

【讨论】：

【解决方案2】：

关于应用服务器是否应该等待连接的问题，答案是肯定的。

MySQL 连接被阻塞。当您通过连接从 MySQL 服务器发出请求时，连接将等待，处于空闲状态，直到收到来自服务器的响应。

没有办法在同一个连接上发送两个请求，看看哪个先返回。您一次只能发送一个请求。

因此，通常，连接池中的单个线程由一个客户端连接（在您的情况下，应用程序服务器是客户端）和一个服务器端连接（数据库）组成。

您的应用程序应该等待池中的可用连接线程，允许池在需要时增长，并在不那么忙时收缩回您的默认线程数。

【讨论】：