Комментарии 12
А вы можете для не самых умных объяснить зачем? Зачем нужно использовать целую Кафку для синхронных взаимодействий если можно напрямую послать запрос в "микросервис-publisher"?
Это просто оверинжиниринг 80-го уровня получается.
В пошаговых инструкциях как то не нашел, как реализован принцип то, на чем это основано. Это фича Кафки, или Спринга? Нельзя ли добавить пункт с теорией, что бы не разбирать весь текст?
Вот мне тоже кажется, что при наличии нескольких экземпляров приложения это так просто не заработает, потому что обработка разных партиций топика с ответом вполне себе окажется на разных инстансах. Не обязательно на тех, откуда отправляли запрос.
В итоге пример классный, но как будто бесполезный в реальной жизни.
Инстансы разные, но код обработки ответа-то один и тот же. Какая разница, какой из инстансов его поймал?
При асинхронной обработке - разницы нет. Но тут то смысл в том, что конкретный инстанс начинает "синхронно" ожидать ответ после запроса:
NotificationDispatchResponse dispatch(NotificationDispatchRequest notificationDispatchRequest) {
String requestTopic = synchronousKafkaProperties.requestTopic();
ProducerRecord<String, NotificationDispatchRequest> producerRecord = new ProducerRecord<>(requestTopic, notificationDispatchRequest);
var requestReplyFuture = replyingKafkaTemplate.sendAndReceive(producerRecord);
return requestReplyFuture.get().value();
}Точно. Тогда нужна идентификация "своих" сообщений 🤷♂️
@spring_aio было бы круто, если бы вы отвечали на комментарии к своим статьям. Иначе выглядит как бездумный перевод ради накрутки подписчиков.
Главный плюс мог быть в том, чтобы использовать Кафку как надежного брокера с повторами изнутри при падении основного приложения и его рестарте. Например в сложных распределенных сценариях вызовов разных систем или работы с разными бд, когда из-за падения приложения разваливается вся логическая транзакция и нужно например повторять идемпотнентно (если возможно).
Но автор ничего не рассказал о теории и что будет с хэшмапой и сохранёнными в памяти коррелейшен ID при падении приложения или рестарте на половине выполненной логической транзакции.
Короче не хватает реальных примеров, когда этот подход реально дает профит и выручает. А когда наоборот вреден и всё сильно усложняет.
Особенно интересно всё это в купе с синхронным выполнением всей операции.
Что будет при таймауте свыше 30 секунд (Кафка упала или сеть)? Событие где-то останется? Ответ позже сформируется доработав по логике сценария даже если вызывающая сторона уже по таймауту отвалилась ведь сценарий был синхронным?
А под капотом там CompletableFuture? А если приложение запущено в нескольких экземплярах и запрос направил один экземпляр, а ответ принял другой?
Kafka умеет синхронно. В Spring Boot