Мне кажется более оптимальным решением будет отправлять сообщение в кафка после коммита транзакции в бд, но сохранение сообщения в бд оставить. Потом самим же подписаться на этот топик, получать сообщение с тем же ИД и удалять его из бд. Если мы длительно время не получаем сообщение от кафка, то отправляем его туда из бд. Надеюсь понятно объяснил.
Смотрел видео как буд-то впервые. А тут мое сообщение)) Я удивился, ведь у меня теперь другая точка зрения - не надо ничего слать напрямую в кафку вне транзакции бд даже если это кажется более эффективным решением.
Tldr: exactly once в kafka сделан для самой же kafka при путешествии данных из топика в другой. В остальных случаях прийдется городить дедупликацию на консьюмере используя бд, либо закладывать atleast-once на этапе проектирования.
Exactly-once сделан для того, чтобы не дублировалось одно и то же сообщение от продюсера пре ретраях (если например сообщение было успешно записано в партицию, но ack сообщение потерялось). Путешествие данных из топика в другой здесь абсолютно не при чем. При этом дублирование может возникать на консьюмере, потому что одно и то же сообщение может быть им прочитано несколько раз, если у него не получилось по какой-то причине закоммитить оффсет.
ruclips.net/video/fGP0qoB78Nw/видео.html т.е. перед тем как отправить сообщение в брокер, мы его сохраним в бд, потом вычитаем из бд и отправим в брокер??? тогда нафига брокер спрашивается, если мы тут нагородили свою очередь? не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд, а в случае ошибки отправки в брокер делать ретрай?
"не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд" - возникает друга проблема, у тебя может упасть приложение после транзакции, тогда никакого сообщения в kafke ты не отправишь, а транзакция уже закрыта и приложение думает, что все хорошо. Ретрай в таком кейсе не поможет, приложение упало, условно сервер вырубился. Когда оно поднимется ретраить оно уже ничего не будет. Плюс ретрай может быть долгим в твоем сценарии, а тебе возможно нужно уже ответ пользователю вернуть, а ты ждешь ретрай. Идея в видео - записать информацию о необходимости отправки той же транзакцией чтобы не ждать и ничего не потерять, а потом отдельно обработать отправку в kafka. в другом процессе.
Мне кажется тут может быть еще одна серьезная проблема - это нарушение строгой очередности событий. Из примера на видео представьте, что мы сохранили транзакцию о созданном заказе в бд и сразу отправили сообщение в брокер, то это сообщение может записаться в брокер быстрее чем другое событие по этому заказу (ведь они тоже пытаются сразу в брокер так же попасть), в итоге за это время несколько раз сменился статус.. и получается что статус несколько раз сменился, а на стороне консюмера мы не знаем какое событие сначала обрабатывать - статус заказа Ready или Processed.
Очень понятное и детальное объяснение работы с exactly-once в kafka. Благодарности докладчику.
Отличный и полезный доклад! Спасибо!
в поделке sarama метод Commit у ConsumerGroupSession не возвращает ошибку, эта полова не для production
Как реализуется механизм ровно однократной гарантированной передачи сообщения?
Без привлечения продюсеров/потребителей не получится ведь?
Прекрасный обзорный доклад! Вопрос, не будут ли разрастаться таблички "outbox/inbox" со временем?
Мне кажется более оптимальным решением будет отправлять сообщение в кафка после коммита транзакции в бд, но сохранение сообщения в бд оставить. Потом самим же подписаться на этот топик, получать сообщение с тем же ИД и удалять его из бд. Если мы длительно время не получаем сообщение от кафка, то отправляем его туда из бд. Надеюсь понятно объяснил.
Смотрел видео как буд-то впервые. А тут мое сообщение)) Я удивился, ведь у меня теперь другая точка зрения - не надо ничего слать напрямую в кафку вне транзакции бд даже если это кажется более эффективным решением.
Курьезная ситуация😂 Если бы не даты, то можно принять за раздвоенип личности)
@@StrangerFromAnotherDay 😁
Tldr: exactly once в kafka сделан для самой же kafka при путешествии данных из топика в другой. В остальных случаях прийдется городить дедупликацию на консьюмере используя бд, либо закладывать atleast-once на этапе проектирования.
Exactly-once сделан для того, чтобы не дублировалось одно и то же сообщение от продюсера пре ретраях (если например сообщение было успешно записано в партицию, но ack сообщение потерялось). Путешествие данных из топика в другой здесь абсолютно не при чем. При этом дублирование может возникать на консьюмере, потому что одно и то же сообщение может быть им прочитано несколько раз, если у него не получилось по какой-то причине закоммитить оффсет.
ruclips.net/video/fGP0qoB78Nw/видео.html т.е. перед тем как отправить сообщение в брокер, мы его сохраним в бд, потом вычитаем из бд и отправим в брокер??? тогда нафига брокер спрашивается, если мы тут нагородили свою очередь? не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд, а в случае ошибки отправки в брокер делать ретрай?
"не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд" - возникает друга проблема, у тебя может упасть приложение после транзакции, тогда никакого сообщения в kafke ты не отправишь, а транзакция уже закрыта и приложение думает, что все хорошо. Ретрай в таком кейсе не поможет, приложение упало, условно сервер вырубился. Когда оно поднимется ретраить оно уже ничего не будет. Плюс ретрай может быть долгим в твоем сценарии, а тебе возможно нужно уже ответ пользователю вернуть, а ты ждешь ретрай.
Идея в видео - записать информацию о необходимости отправки той же транзакцией чтобы не ждать и ничего не потерять, а потом отдельно обработать отправку в kafka. в другом процессе.
Мне кажется тут может быть еще одна серьезная проблема - это нарушение строгой очередности событий. Из примера на видео представьте, что мы сохранили транзакцию о созданном заказе в бд и сразу отправили сообщение в брокер, то это сообщение может записаться в брокер быстрее чем другое событие по этому заказу (ведь они тоже пытаются сразу в брокер так же попасть), в итоге за это время несколько раз сменился статус.. и получается что статус несколько раз сменился, а на стороне консюмера мы не знаем какое событие сначала обрабатывать - статус заказа Ready или Processed.