Exactly-once Kafka | Артём Кулешов | Golang Meetup 2023 | СберМаркет Tech
Вставка
- Опубліковано 27 кві 2023
- Доклад будет полезен разработчикам, работающим с Kafka. Поговорим про подводные камни и как их избежать. Рассмотрим паттерны проектирования и важные настройки клиентов и топиков.
Спикер: Артём Кулешов, старший разработчик в CберМаркет Tech
Мы Tech-команда, которая создает e-grocery сервис #1 в России и делает это с любовью.
Telegram: t.me/sbermarket_tech VK: sbermarket_tech
Блог на Хабре: bit.ly/habr-all
Вакансии: team.sbermarket.ru/tech
Подкаст «Для tech и этих»: bit.ly/dlya-tech-i-etich-podcast - Розваги
Очень понятное и детальное объяснение работы с exactly-once в kafka. Благодарности докладчику.
Отличный и полезный доклад! Спасибо!
Tldr: exactly once в kafka сделан для самой же kafka при путешествии данных из топика в другой. В остальных случаях прийдется городить дедупликацию на консьюмере используя бд, либо закладывать atleast-once на этапе проектирования.
Прекрасный обзорный доклад! Вопрос, не будут ли разрастаться таблички "outbox/inbox" со временем?
в поделке sarama метод Commit у ConsumerGroupSession не возвращает ошибку, эта полова не для production
Как реализуется механизм ровно однократной гарантированной передачи сообщения?
Без привлечения продюсеров/потребителей не получится ведь?
Мне кажется более оптимальным решением будет отправлять сообщение в кафка после коммита транзакции в бд, но сохранение сообщения в бд оставить. Потом самим же подписаться на этот топик, получать сообщение с тем же ИД и удалять его из бд. Если мы длительно время не получаем сообщение от кафка, то отправляем его туда из бд. Надеюсь понятно объяснил.
Смотрел видео как буд-то впервые. А тут мое сообщение)) Я удивился, ведь у меня теперь другая точка зрения - не надо ничего слать напрямую в кафку вне транзакции бд даже если это кажется более эффективным решением.
Курьезная ситуация😂 Если бы не даты, то можно принять за раздвоенип личности)
@@StrangerFromAnotherDay 😁
ua-cam.com/video/fGP0qoB78Nw/v-deo.html т.е. перед тем как отправить сообщение в брокер, мы его сохраним в бд, потом вычитаем из бд и отправим в брокер??? тогда нафига брокер спрашивается, если мы тут нагородили свою очередь? не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд, а в случае ошибки отправки в брокер делать ретрай?
"не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд" - возникает друга проблема, у тебя может упасть приложение после транзакции, тогда никакого сообщения в kafke ты не отправишь, а транзакция уже закрыта и приложение думает, что все хорошо. Ретрай в таком кейсе не поможет, приложение упало, условно сервер вырубился. Когда оно поднимется ретраить оно уже ничего не будет. Плюс ретрай может быть долгим в твоем сценарии, а тебе возможно нужно уже ответ пользователю вернуть, а ты ждешь ретрай.
Идея в видео - записать информацию о необходимости отправки той же транзакцией чтобы не ждать и ничего не потерять, а потом отдельно обработать отправку в kafka. в другом процессе.
Мне кажется тут может быть еще одна серьезная проблема - это нарушение строгой очередности событий. Из примера на видео представьте, что мы сохранили транзакцию о созданном заказе в бд и сразу отправили сообщение в брокер, то это сообщение может записаться в брокер быстрее чем другое событие по этому заказу (ведь они тоже пытаются сразу в брокер так же попасть), в итоге за это время несколько раз сменился статус.. и получается что статус несколько раз сменился, а на стороне консюмера мы не знаем какое событие сначала обрабатывать - статус заказа Ready или Processed.