Виртуальные потоки против реактивных драйверов базы данных

Виртуальные потоки против реактивных драйверов базы данных ⇐ JAVA

1 сообщение • Страница 1 из 1

Anonymous

Виртуальные потоки против реактивных драйверов базы данных

Цитата

Сообщение Anonymous » 02 май 2026, 07:07

Есть типичная задача: получить данные из Kafka (или REST/gRPC), обработать их и сохранить в БД.
База данных всегда была нашим слабым местом. Обычно нам приходится обрабатывать сотни или тысячи сообщений в минуту, и нам разрешено использовать только дюжину подключений к БД. Большинство запросов выполняются быстро (миллисекунды), но некоторые могут занимать соединение в течение нескольких секунд.
Наше типичное решение:

Семафор емкостью N
ThreadPoolExecutor с количеством потоков N
Пул соединений N + 1 и JDBC (1 соединение зарезервировано для Heartbeat/liveness проба)

Если сообщение прошло семафор, оно обрабатывается в отдельном потоке и в конечном итоге использует отдельное соединение JDBC из пула. Семафор нужен для сглаживания пиков нагрузки: он отклоняет или отправляет сообщения обратно в тему повтора, предотвращая чрезмерное накопление в очереди пула потоков (экономит память) и защищает от потери слишком большого количества сообщений при принудительном закрытии модулей.
Это работает достаточно хорошо, но теперь пришло время масштабирования — мы собираемся обрабатывать миллионы сообщений, и мне интересно, что поможет нам лучше использовать ресурсы. У нас по-прежнему есть ограничения в 10–50 одновременных подключений к базе данных, и мы должны обрабатывать сообщения как можно быстрее, в идеале с одинаковым использованием ЦП/памяти, но, как я уже говорил, узким местом является ограниченный пул соединений, а не нехватка ресурсов на уровне приложения.
Я рассматриваю два решения и, возможно, их сочетание:

Виртуальные потоки + блокировка JDBC
Драйвер реактивной БД (клиент Vert.x pg, поскольку соседняя команда имеет опыт работы с ним, но возможны и другие решения)

Виртуальные потоки считаются серебряной пулей для всех проблем блокировки API (в частности, JDBC). Говорят, они убивают реактивное программирование, которое было всего лишь переходной технологией... В моем понимании VT легко могут заменить ThreadPoolExecutor; они дешевле и все такое. Но действительно ли они решат проблему ограниченного пула соединений?
Что происходит, когда виртуальный поток отправляет запрос к базе данных и приостанавливается? Будет ли соединение JDBC освобождено для обработки других запросов/ответов во время ожидания ответа на первый запрос? Или он все еще будет занят из-за блокирующего характера драйвера JDBC (поэтому потоки платформы готовы выполнять больше задач, а пул соединений - нет, поскольку все соединения заняты)?
Мне тоже не ясно, как на самом деле работают реактивные драйверы базы данных. Что произойдет, когда они отправят запрос к БД (отправят последний байт в сеть) - вернется ли соединение в пул? Если да, то как БД управляет контекстами сеансов для множества запросов и ответов, отделенных друг от друга в этом асинхронном взаимодействии?..

1777694822

Anonymous

Есть типичная задача: получить данные из Kafka (или REST/gRPC), обработать их и сохранить в БД.
База данных всегда была нашим слабым местом. Обычно нам приходится обрабатывать сотни или тысячи сообщений в минуту, и нам разрешено использовать только дюжину подключений к БД. Большинство запросов выполняются быстро (миллисекунды), но некоторые могут занимать соединение в течение нескольких секунд.
Наше типичное решение:
[list]
[*]Семафор емкостью N
[*]ThreadPoolExecutor с количеством потоков N
[*]Пул соединений N + 1 и JDBC (1 соединение зарезервировано для Heartbeat/liveness проба)
[/list]
Если сообщение прошло семафор, оно обрабатывается в отдельном потоке и в конечном итоге использует отдельное соединение JDBC из пула. Семафор нужен для сглаживания пиков нагрузки: он отклоняет или отправляет сообщения обратно в тему повтора, предотвращая чрезмерное накопление в очереди пула потоков (экономит память) и защищает от потери слишком большого количества сообщений при принудительном закрытии модулей.
Это работает достаточно хорошо, но теперь пришло время масштабирования — мы собираемся обрабатывать миллионы сообщений, и мне интересно, что поможет нам лучше использовать ресурсы. У нас по-прежнему есть ограничения в 10–50 одновременных подключений к базе данных, и мы должны обрабатывать сообщения как можно быстрее, в идеале с одинаковым использованием ЦП/памяти, но, как я уже говорил, узким местом является ограниченный пул соединений, а не нехватка ресурсов на уровне приложения.
Я рассматриваю два решения и, возможно, их сочетание:
[list]
[*][b]Виртуальные потоки + блокировка JDBC[/b]
[*][b]Драйвер реактивной БД[/b] (клиент Vert.x pg, поскольку соседняя команда имеет опыт работы с ним, но возможны и другие решения)
[/list]
[b]Виртуальные потоки[/b] считаются серебряной пулей для всех проблем блокировки API (в частности, JDBC). Говорят, они убивают реактивное программирование, которое было всего лишь переходной технологией... В моем понимании VT легко могут заменить ThreadPoolExecutor; они дешевле и все такое. Но действительно ли они решат проблему ограниченного пула соединений?
Что происходит, когда виртуальный поток отправляет запрос к базе данных и приостанавливается? Будет ли соединение JDBC освобождено для обработки других запросов/ответов во время ожидания ответа на первый запрос? Или он все еще будет занят из-за блокирующего характера драйвера JDBC (поэтому потоки платформы готовы выполнять больше задач, а пул соединений - нет, поскольку все соединения заняты)?
Мне тоже не ясно, как на самом деле работают [b]реактивные драйверы базы данных[/b]. Что произойдет, когда они отправят запрос к БД (отправят последний байт в сеть) - вернется ли соединение в пул? Если да, то как БД управляет контекстами сеансов для множества запросов и ответов, отделенных друг от друга в этом асинхронном взаимодействии?..