Прочитал вот это вот:
https://www.baeldung.com/spring-reactor

скачал себе:

https://github.com/eugenp/tutorials/tree/master/spring-5-reactive

и так и не понял в чём профит от этих Flux и Mono

Что значит, что репозиторий должен быть реактивным?

Может кто на пальцах объяснить зачем это надо?

Чем это отличается от асинхронных сервлетов?

maytonТак Баелдунг в начале статьи и пишет Why reactor.

А по поводу чем оно отличается от асинхронных сервлетов - я не знаю. Ты расскажи что это такое за сервлеты.

Там какая-то вода написана.

https://www.baeldung.com/spring-reactor The reactive design pattern is an event-based architecture for asynchronous handling of a large volume of concurrent service requests coming from single or multiple service handlers.

And the Spring Reactor project is based on this pattern and has the clear and ambitious goal of building asynchronous, reactive applications on the JVM.
Мой перевод:
Есть какой-то там паттерн, который помогает строить асинхронные реактивные приложения(что это на самом деле непонятно).
Этот паттерн основан на событийной архитектуре для асинхронной обработки большого количества конкурентных запросов к сервисам приходящих от одного или нескольких сервис хэндлеров.

Честно, я не особо вкурил, что это значит.


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

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

Честно, я не особо вкурил, что это значит.

Смотри. Если ты делаешь интернет магазин на 5-10 чел. То тебе пофиг какой там будет Реакт или Не-реакт.
Ты разницы не заметишь. Но если ты кодишь hi-load. И утебя 10000 Threads висят но ожидании I/O то ... учоные
установили что в этом случае лучше "ожидать" это событие по другому. Вот про это и эти рекативные фреймворки.

По поводу реактивного сервлета. Не уверен. Надо смотреть. Callable/Future - это просто обёртки которые
ничего не делают и просто обладают контрактом. Надо смотреть какой двигатель их двигает.

Пользователям Node.JS скорее всего подобные фреймворки не нужны вообще. У них такой I/O изначально был заложен.

Сервлеты не реактивные, а асинхронные)


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

Sergunkaquestionerпропущено...


Там какая-то вода написана.

пропущено...

Мой перевод:
Есть какой-то там паттерн, который помогает строить асинхронные реактивные приложения(что это на самом деле непонятно).
Этот паттерн основан на событийной архитектуре для асинхронной обработки большого количества конкурентных запросов к сервисам приходящих от одного или нескольких сервис хэндлеров.

Честно, я не особо вкурил, что это значит.


На самом деле Вы правильно перевели, но не поняли прочитанного. Для того, чтоб понять надо видимо прочитать что означает reactive - responsive, scalable, and recilient. Т.е. русским языком ваша апп не падает, маштабируется и эластична (другими словами если шаблон начинает рваться, то автоматически добавляется количество нодов в нашем примере потоков типо)

Дальше надо не поленится и глянуть в код (лучше склонировать гитхаб... надеюсь все умеют ) запустить апликуху и посмотреть как дело происходит.

В общем идем в
https://github.com/eugenp/tutorials/blob/master/spring-reactor/src/main/java/com/baeldung/Config.java

смотрим на бин




Смотрим в коде библиотеки что означает Environment.THREAD_POOL




Опа-на! Так это всеми нами так горячо любимый пул экзекьютор

Надеюсь всем полегчало... хорошего дня коллеги

А зачем тогда база данных должна быть реактивной?

Вот тут пишут про реактивный АПИ к couchbase https://blog.couchbase.com/why-you-should-care-about-reactive-database-access/

Как по мне - профита не много.

синхронный вариант:


Реактивный вариант:



Ок. В синхронном варианте мы берем пост, потом первый коммент, второй коммент

В реактивном - сначала пост тянем, потом параллельно комменты

В синхронном варианте эту логику тоже можно руками написать и сильно не перетрудиться.

реактивно = асинхроннно + что-то.

Это так?

Озверинquestioner, наверное потому, что стандартные имплементации jdbc - используют блокирующие стримы.Чтобы добиться асинхронного блокирующего вызова, требуется создать +1 поток. Т.е. - сам вызов базы и основной поток, который будет ждать обращения к базе, потому что оно блокирующее. Это сделать достатчно легко, но в итоге мы получим проблему: -n+1 потоков

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

Я примерно так понимаю проблемы реактивного программирования в разрезе - зачем же реактивные репозитории.

Это ж обычная ORM-ная n+1 проблема.

Озверинстандартные имплементации jdbc - используют блокирующие стримы
на английском стрим как тут будет? (Thread или java-8 Stream или IO stream?)

Почему в одном случае поток живёт долго, а в другом не долго? я не понимаю этого

Как по мне в обоих случаях надо делать следующее.

Thread_1 достаёт сущность Post, идёт по commentId и создаёт Runnable для каждой для доставания коммента и отправляет в экзекутор, делаем волатильную атомик переменную инкремент которой происходит по доставанию коммента и когда счётчик достиг двух - тушим экзекутор, ну и чистим коллекцию если больше двух комментов было подтянуто. ну и кстати тогда мы достанем 2 рандомных коммента, а просят 2 первых.

https://blog.couchbase.com/why-you-should-care-about-reactive-database-access/ Now let's say we want to load the first two comments that are published when the blog post is loaded

Озверинquestioner, очепяталсо, не стрим а сокет.

Ну стандартная n+1 проблема в orm заключается чуть чуть в другом - неконтроллируем рост обращений к базе, но итог - да, примерно похожий.

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

Хотите сказать, что бывают какие-то волшебные неблокирующие сокеты?

Это ведь в любом случае IO и оно может очень не хило тормозить.