Как ограничить соединения DB в массовом масштабе Java-приложение

Question

У меня есть приложение Java с более чем 100 серверами. В настоящее время каждый сервер открывает соединения с 7 схемами базы данных в реляционных базах данных (протоколирование, это, это, другое). Все схемы подключаются к одному и тому же кластеру БД, но все это фактически один экземпляр базы данных.

Пулы подключений, управляемые сервером, открывают множество соединений (1-5) для каждой схемы базы данных на один экземпляр, а затем удваивают их в избыточном пуле. Таким образом, каждый сервер открывает минимум 30 подключений к базе данных и может вырасти до нескольких сотен на сервер, а также более 100 серверов.

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

Очевидно, что это просто неправильно. Кластер базы данных может эффективно выполнять только X одновременных запросов и любое количество запросов.> X вводит ненужное утверждение и замедляет работу всей партии. (X неизвестен, но он меньше, чем 3000 минимальных одновременных соединений).

Я хочу, чтобы снизить общее количество соединений, используемых путем реализации следующей стратегии: только

1. Подключение к одной схеме (Application-X), имеет 6 соединений на максимум бассейна.
2. Напишите слой над пулом, который переключится на схему, которую я хочу. Функция getConnection (forSchema) будет принимать параметр для целевой схемы (например, протоколирование), получит соединение, которое может продолжаться, указывая на любую схему, и выдает оператор SQL-запроса схемы (задайте путь_ search_path к 'target_schema').

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

Мой вопрос заключается в том, есть ли реализация пула БД, которая уже делает это, - позволяет мне иметь один набор соединений и автоматически помещает меня в правильную схему или, еще лучше - отслеживает, доступно ли объединенное соединение для ваша целевая схема, прежде чем принимать решение идти вперед и переключать схему (экономит поездку в оба конца).

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

Answer 1

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

Вот почему это работает:

Медленная часть веб-запрос может быть возврат данных клиента. Если есть много данных или пользователь находится на медленном соединении, соединение может оставаться открытым для веб-сервера, где данные медленно перетекают к клиенту. Между тем, сервер приложений продолжает поддерживать соединение с базой данных, доступное для серверного сервера. Хотя подключение к базе данных может потребоваться только для части транзакции, она привязана до тех пор, пока клиент не отключится от сервера приложений.

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

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

После изменения количество требуемых ручек базы данных было намного меньше и намного более стабильным.

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