MySQL - Постоянное соединение и объединение пулов

Чтобы избежать накладных расходов на установление нового соединения каждый раз, когда запрос необходимо запустить против MySQL, доступны два варианта:

Постоянные соединения, при которых запрашивается новое соединение, проверяется, открыто ли "идентичное" соединение и если оно его использует.
Пул соединений, при котором клиент поддерживает пул соединений, так что каждый поток, который должен использовать соединение, будет проверять один из пула и возвращать его обратно в пул, когда это будет сделано.

Итак, если у меня есть многопоточное серверное приложение, которое должно обрабатывать тысячи запросов в секунду, и каждый поток должен запускать запрос к базе данных, то какой вариант лучше?

С моей точки зрения, при постоянных подключениях все потоки в моем приложении будут пытаться использовать одно и то же постоянное соединение с базой данных, потому что все они используют одинаковые соединения. Таким образом, это одно соединение, разделенное между несколькими потоками приложений - в результате в ближайшее время запросы будут блокироваться на стороне базы данных.

Если я использую механизм объединения пулов, у меня будут все потоки приложений, совместно использующие пул соединений. Таким образом, существует меньше возможности запроса блокировки. Однако при подключении пула приложений, если поток приложений ожидает получения соединения из пула или должен ли он отправлять запрос на соединения в пуле в любом случае циклически, и пусть очереди, если они есть, происходят в базе данных?

Ответ 1

Наличие постоянных соединений не означает, что все потоки используют одно и то же соединение. Он просто "говорит", что вы держите соединение открытым (в противоположность открытому соединению каждый раз, когда вам это нужно). Открытие соединения - дорогостоящая операция, поэтому - в целом - вы стараетесь не открывать соединения чаще, чем необходимо.

Вот почему многопоточные приложения часто используют пулы подключений. Пул заботится об открытии и закрытии соединений, и каждый поток, которому требуется соединение, запрашивает один из пула. Важно позаботиться о том, чтобы нить вернула соединение как можно скорее в пул, чтобы другой поток мог его использовать.

Если ваше приложение имеет только несколько длинных потоков, требующих соединений, вы также можете открыть соединение для каждого потока и оставить его открытым.

Использование только одного соединения (как вы описали его) равно пулу соединений с максимальным размером одного. Это будет рано или поздно вашим узким местом, так как все потоки должны будут ждать подключения. Это может быть вариант сериализации операций с базой данных (выполнить их в определенном порядке), хотя есть более эффективные варианты обеспечения сериализации.

Ответ 2

Что касается вашего вопроса о том, должен ли сервер приложений ждать соединения, ответ будет да.

Соединения MySQL блокируются. Когда вы выдаете запрос от сервера MySQL через соединение, соединение будет ждать, простаивает, пока не будет получен ответ от сервера.

Невозможно отправить два запроса в одно и то же соединение и посмотреть, какие из них возвращаются. Вы можете отправлять только один запрос за раз.

Итак, как правило, один поток в пуле подключений состоит из одного клиентского соединения (в вашем случае сервер приложений - это клиент) и одно серверное соединение (база данных).

Ваше приложение должно ждать доступного потока подключений из пула, позволяя пулу расти, когда это необходимо, и сжиматься до вашего количества потоков по умолчанию, когда оно менее занято.