Безболезненная миграция с NATS на Kafka

[ababo]

А какова была мотивация/целеполагание в переходе с NATS на Kafka?

[mkorobovv]

На самом деле, основная причина тому была частые сбои сервера NATS, что заставляло пользователей ждать, когда заново поднимут кластеры, с Kafka почему-то таких проблем не наблюдалось.

[savostin]

Странная мотивация если честно. Может кластер из 3+ решил все проблемы? Ну или таки посмотреть логи почему они падают…

[mkorobovv]

Я бы с радостью остался на NATS, но, к сожалению, это была вынужденная мера, на которую бэкэнд разработчики никак повлиять не могли.

[dilmuradov]

А если у тебя сервис паралельно будет работать в двух инстансах. У тебя должно быть какая-то распредельенный блокер чтобы воркеры параллельно не обрабатывали одну и ту же данные.

[mkorobovv]

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

UPD: даже если такое как-то произойдет, замысел инбокса это обработка сообщений at least once. Таким образом, не страшно, если запись дважды обработается.

[sanzhi]

Есть способ для параллельного разгребания таблицы inbox несколькими инстансами без дополнительных полей. Каждый инстанс должен брать записи из таблицы с помощью select for update skip locked.

[alexanderfedyukov]

База данных не стала бутылочным горлышком после реализации Inbox? Если не стала, то может и NATS\Kafka не нужнs для вашей задачи и всю обработку можно организовать на уровне бд?

[mkorobovv]

Не стала, в данной теме я раскрыл только реализацию самой задачи на уровне микросервиса. Если говорить про общую архитектуру, то на топик кафки, помимо рассматриваемого микросервиса, еще могут быть подписаны другие сервисы, поэтому удачным решением было бы здесь использовать брокера, чтобы не стучаться в каждый сервис по HTTP.

[fuCtor]

Судя по тексту, вы использовали не чистый NATS, а его компонент JetStream.

Почему Kafka? Почему не отказались от JetStream и остались на Nats + DB?

[mkorobovv]

На проекте использовался NATS Streaming. Как описал в комментарии на похожий вопрос выше, проблема была в частых сбоях кластеров NATS. Инициатива была не наша, поэтому полностью раскрыть причину не получится. В статье я лишь привел пример и сравнил работу с брокерами Kafka и NATS Streaming.

[ilving]

Если честно, то я не уловил необходимости складывать все данные в бд, а потом грузить ее выборками и апдейтами, причем с locked_until (выше уже писали про for update skip locked, хотя это решение тоже имеет подводные камни).

На мой вкус бд имеет смысл только для отложенных сообщений, и приправляется сверху exponential backoff и, при необходимости, лимитом на количество попыток. И ещё можно подумать и переложить очередь ретраев на редис - он с этим работает сильно быстрее чем постгря

[mkorobovv]

Основным аргументом для добавления инбокса была проблема с ошибочными запросами в third party сервис. А что делать с ошибочными данными в кафке непонятно. Можно было добавить retry topic или инбокс, тут уже все на свой вкус. На своем опыте могу сказать, что постгрес отрабатывает достаточно быстро, если понадобится редис, то внедрим и его, а преждевременная оптимизация обычно ни к чему хорошему не приводит.

[ilving]

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

Меня смущает сама идея организации ещё одной полноценной очереди из постгри.

[covalski]

Хорошая и содержательная статья! Будет интересно почитать другие статьи автора