Согласно руководству по реагированию на данные micronaut,
... В случае реактивного выполнения и если поддерживающая реализация блокируется, Micronaut Data будет использовать настроенный пул потоков ввода-вывода для планирования выполнения запроса в другом потоке.
Если поддерживающая реализация изначально поддерживает реактивные типы на уровне драйвера, тогда пул потоков ввода-вывода не используется, и вместо этого предполагается, что драйвер будет обрабатывать запрос неблокирующим образом ...
Мой прямой вопрос: доступ к реляционной базе данных (например, PostGres драйвер R2DBC) бросит R2DBC будет Micronaut Data полагаться на то, что драйвер R2DBC будет обрабатывать неблокирующим образом и будет более масштабируемым?
Предположим, что мой микросервис предоставляет реактивную конечную точку на основе ReactiveX и должен получить доступ к блокирующему источнику данных throw Micronaut Data JDBC (например, Oracle R2DBC еще не находится в производственной версии), из вышесказанного ясно, что он будет использовать настраиваемый пул потоков ввода-вывода при доступе к данным. Я полностью теряю преимущества реактивной конечной точки?
Это мой первый проект с Micronaut, и у меня есть несколько проектов с реактивным подходом. Я далек от того, чтобы быть экспертом в передовых методах реагирования, но я помню, что читал в нескольких блогах: избегайте использования реактивного стека, если у вас есть блокирующий источник. Я также помню, как читал, что у вас может быть худший результат, смешивая неблокирующий с блокирующим дизайном, в основном из-за того, как спроектирован цикл событий (например, Netty). Поскольку я буду использовать Micronaut с ReactiveX и реляционной базой данных, в некоторых случаях с R2DBC и в других с JDBC, я буду признателен за любые комментарии по поводу моих сомнений.
