#mysql #spring-boot #connection-pooling #hikaricp
Вопрос:
Я работаю над разработкой микросервиса на основе spring-boot, в котором одновременно будут работать десятки экземпляров приложений. Я планирую использовать HikariCP в качестве нашего инструмента объединения подключений к базам данных для подключения к базам данных MySQL. Однако, когда я пытаюсь создать пулы соединений размером от 0 до 10, я могу создавать пулы соединений размером от 1 до 10, но никогда не достигаю значения 0 во время простоя.
Моя конфигурация,
HikariConfig hikariConfig = new HikariConfig(); hikariConfig.setMinimumIdle(0); hikariConfig.setMaximumPoolSize(10); hikariConfig.setIdleTimeout(60000); hikariConfig.setPoolName(poolName); hikariConfig.setJdbcUrl(jdbcUrl); hikariConfig.setUsername(userName); hikariConfig.setPassword(password); hikariConfig.setDriverClassName(databaseDriverClass); return new HikariDataSource(hikariConfig); Я хотел бы понять, есть ли у HikariCP жесткий предел, при котором он никогда не может достигать размера менее 1 неработающего соединения?
Комментарии:
1. Что плохого в минимальном размере 1? Если размер равен нулю, то для выполнения первого поступающего запроса потребуется некоторое время. Кроме того, я бы подумал, что пулу требуется 1 соединение для проверки сердцебиения в ядре базы данных; вероятно, он отправляет фиктивные запросы молча и периодически, чтобы проверить это.
2. Минимальный размер 1-огромная проблема, когда у вас 50 экземпляров одного и того же приложения. И если соединения простаивают, в любой момент времени у вас может быть до 50 соединений, которые простаивают и бесполезны. Наши базы данных являются общими, так что у нас есть 1 схема на каждого клиента. Для каждой схемы у нас есть отдельный пользователь. Из-за этого нам приходится создавать отдельный пул соединений для каждой схемы
3. В этом случае я бы подумал, что использование оркестратора, такого как Kubernetes или OpenShift, может быть лучшим вариантом. У оркестатора не будет постоянно работать 50 простаивающих экземпляров. Вместо этого у него будет только пара из них, работающих в часы с низким трафиком, и он будет автоматически масштабироваться по мере необходимости в часы средней или высокой нагрузки.
4. Насколько я согласен с тем, что вы только что сказали, внесение этих изменений в инфраструктуру потребует много времени, и в данный момент мы ищем возможное решение изнутри. В идеале мы хотели бы, чтобы пулы соединений увеличивались до нуля во время простоя и снова увеличивались по мере необходимости в течение часа
5. И, кстати, у меня есть приложение SpringBoot, работающее с 10 максимальными экземплярами в OpenShift. Бежит, как ветерок, и сам по себе поднимается и опускается.