HA != XA, разные вещи

Мне ничего не мешает отправить ack, но я не хочу этим управлять, тем более если мне например сообщение из очереди в базу надо надёжно переместить.

что вы понимаете под XA в таком случае?

наверное распределенные транзакции, а не хай эвейлебилити

тогда логично было бы настроить консьюмер таким образом, чтобы ack слался только после полной отработки колбэка.

XA и HA

Да, вот эту хрень

Возможно я не знаю как это сделать. И есть проблема с "полной отработкой", как понять, она полная или нет. Если у меня @transactional на методе, коммит был? Что раньше, коммит в базу или ack?

Вот как раз XA транзакции за тебя эту проблему могут решить. Если у тебя метод @Transactional и в нем вычитывание из очереди и запись в базу, то, пока сообщение в базу не запишется и commit в базе не завершится, в очереди сообщение будет считаться непрочитанным. Да, если transaction manager правильный. Какой-нибудь Atomikos посмотри.

Как раз абстракции XA дают тебе возможность не управлять вручную транзакциями в двух местах. Но беда в том, что не все очереди XA умеют. Да и накладные расходы не очень маленькие на это дело.

Но про накладные расходы могу наврать, лично не замерял 😊

накладные будут, на сколько они критичны - каждый решает сам

Exactly. Даром ничего не будет, надо мерить и решать, готов ли ты мириться с ними в своем конкретном случае.

Подскажите по поводу rabbit , нужно ли из кода проверять существует ли очередь? Если очереди не будет я так понимаю сообщения всё ровно будут уходить просто не будут как либо обрабатываться rabbit&

У меня нет проблем ни с XA ни с рэбитом. Разговор пошел от вопроса Алексея выше про использование рэбита с гарантированной доставкой. А ее у раббита нет...

Зависит от конфигурации серверной части. Есть два основных подхода, в первом созданием очередей рулят на сервере. Второй - очередями рулит клиентский код, модно и молодежно.

Спринговая реализация by default использует второй подход. Если что то пойдёт не так и очереди в к будет - то в лог пишется вал ошибок.

А, понял.

))

Ребят, а как в микросервисной архитектуре реализовать обработку запроса от клиента?

Например, флов такой.
client->s1(initial)->s2|s3|s4->s5|s3->sx(final)->client

s1(initial), sx(final) работают как один микросервис, просто разные endpoints.
s - префикс для микросервиса.

Что в это время происходит с запросом клиента? Ну то есть в случае одного сервера он просто в хендлере сделает всю работу и вернёт ответ, а здесь тогда что?

Нужно как-то понимать, на sx, был ли такой запрос на s1, и если был, то отправить ответ и удалить инфу о запросе, но как это сделать?🤔🤔
А на s1 нужно как-то хранить запросы