Exactly-once Kafka | Артём Кулешов | Golang Meetup 2023 | СберМаркет Tech

Доклад будет полезен разработчикам, работающим с Kafka. Поговорим про подводные камни и как их избежать. Рассмотрим паттерны проектирования и важные настройки клиентов и топиков.
Спикер: Артём Кулешов, старший разработчик в CберМаркет Tech
Мы Tech-команда, которая создает e-grocery сервис #1 в России и делает это с любовью.
Telegram: t.me/sbermarke... VK: sbermar...
Блог на Хабре: bit.ly/habr-all
Вакансии: team.sbermarke...
Подкаст «Для tech и этих»: bit.ly/dlya-te...

[@user-nv5ik7tx9u]

Очень понятное и детальное объяснение работы с exactly-once в kafka. Благодарности докладчику.

[@tumenit]

Отличный и полезный доклад! Спасибо!

[@user-si7he1kz9o]

в поделке sarama метод Commit у ConsumerGroupSession не возвращает ошибку, эта полова не для production

[@wildegor]

Прекрасный обзорный доклад! Вопрос, не будут ли разрастаться таблички "outbox/inbox" со временем?

[@dmitrydimitriadi5184]

Как реализуется механизм ровно однократной гарантированной передачи сообщения? Без привлечения продюсеров/потребителей не получится ведь?

[@alex-0x6b]

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

[@alex-0x6b]

Смотрел видео как буд-то впервые. А тут мое сообщение)) Я удивился, ведь у меня теперь другая точка зрения - не надо ничего слать напрямую в кафку вне транзакции бд даже если это кажется более эффективным решением.

[@StrangerFromAnotherDay]

Курьезная ситуация😂 Если бы не даты, то можно принять за раздвоенип личности)

[@alex-0x6b]

@@StrangerFromAnotherDay 😁

[@kovalevvvvv]

Tldr: exactly once в kafka сделан для самой же kafka при путешествии данных из топика в другой. В остальных случаях прийдется городить дедупликацию на консьюмере используя бд, либо закладывать atleast-once на этапе проектирования.

[@alex-w9q]

Exactly-once сделан для того, чтобы не дублировалось одно и то же сообщение от продюсера пре ретраях (если например сообщение было успешно записано в партицию, но ack сообщение потерялось). Путешествие данных из топика в другой здесь абсолютно не при чем. При этом дублирование может возникать на консьюмере, потому что одно и то же сообщение может быть им прочитано несколько раз, если у него не получилось по какой-то причине закоммитить оффсет.

[@user-dk2xo9hj2m]

kzbin.info/www/bejne/nHizYaSld5xrhNk т.е. перед тем как отправить сообщение в брокер, мы его сохраним в бд, потом вычитаем из бд и отправим в брокер??? тогда нафига брокер спрашивается, если мы тут нагородили свою очередь? не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд, а в случае ошибки отправки в брокер делать ретрай?

[@user-nv5ik7tx9u]

"не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд" - возникает друга проблема, у тебя может упасть приложение после транзакции, тогда никакого сообщения в kafke ты не отправишь, а транзакция уже закрыта и приложение думает, что все хорошо. Ретрай в таком кейсе не поможет, приложение упало, условно сервер вырубился. Когда оно поднимется ретраить оно уже ничего не будет. Плюс ретрай может быть долгим в твоем сценарии, а тебе возможно нужно уже ответ пользователю вернуть, а ты ждешь ретрай. Идея в видео - записать информацию о необходимости отправки той же транзакцией чтобы не ждать и ничего не потерять, а потом отдельно обработать отправку в kafka. в другом процессе.

[@alex-0x6b]

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