Всем привет, такой вопрос по архитектуре: Допустим есть сервис А, который

Question

Всем привет, такой вопрос по архитектуре: Допустим есть сервис А, который

посылает сообщения в очередь (допустим Кафка), в боркере эти сообщения хранятся примерно 1-2 минуту.
Сервис В читает эти сообщения и обрабатывает их, однако возможно случаи, когда сервис В не успеет вычитать сообщения до их удаления из топика и в таком случае, сервису А нужно опять послать эти сообщения в топик.

Вопрос заключается в том, как лучше сделать механизм подтверждения обработки сообщения из топика кафки для сервис В. Ну ум приходит пока что рест запросы из сервиса В в сервис А о прочитанных сообщениях. Кажется это не лучшее решение, возможно уже есть стандартные подходы в таких случаях?

#backend #java #programming #russian

0

30.03.2022

8 ответов

9 просмотров

Ra Автор вопроса

Alexey Genus 😎
Почему бы не увеличить срок хранения сообщений в т...

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

0

30.03.2022

Denis Chikanov

Ra
Логично предположить, что если есть такое условие,...

> Логично предположить, что если есть такое условие, то оно не просто так придумано. Ну вообще нет, люди очень рандомную херню делают часто

0

30.03.2022

Denis Chikanov

но если уж очень хочется - или завести ещё одну очередь с подтверждениями прочтения, или слать в сервис А какие-то подтверждения напрямую, да

0

30.03.2022

Alexey Genus 😎

Ra
Логично предположить, что если есть такое условие,...

Даже, если это решение не просто так придумано, почему бы его не поменять? В целом вижу три варианта 1. кидать сообщения в ответный топик, который читает сервис А 2. Вызывать коллбэк из сервиса Б в А 3. Сделать в сообщениях неразрывный sequence number. При детектировании “разрыва” сервис Б посылает запросу сервису А о необходимости переотправки

0

30.03.2022

Denis Chikanov

Alexey Genus 😎
Даже, если это решение не просто так придумано, по...

притом версия 3 кажется плохо скейлится

0

30.03.2022

Viacheslav Ledovskih

Alexey Genus 😎
Даже, если это решение не просто так придумано, по...

Пункт 2 - получаем странную зависимость, которая зависит от доступности сервиса А

0

30.03.2022