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

Поделиться
HTML-код
  • Опубликовано: 22 дек 2024

Комментарии • 14

  • @ВладиславЛатиш
    @ВладиславЛатиш Год назад +1

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

  • @tumenit
    @tumenit Год назад

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

  • @СергейИванов-э8с
    @СергейИванов-э8с Год назад +1

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

  • @dmitrydimitriadi5184
    @dmitrydimitriadi5184 Год назад

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

  • @wildegor
    @wildegor 6 месяцев назад

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

  • @alex-0x6b
    @alex-0x6b Год назад

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

    • @alex-0x6b
      @alex-0x6b 10 месяцев назад

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

    • @StrangerFromAnotherDay
      @StrangerFromAnotherDay 5 месяцев назад +3

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

    • @alex-0x6b
      @alex-0x6b 5 месяцев назад

      @@StrangerFromAnotherDay 😁

  • @kovalevvvvv
    @kovalevvvvv 11 месяцев назад

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

    • @alex-w9q
      @alex-w9q 4 месяца назад +2

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

  • @ВасяВ-ь5м
    @ВасяВ-ь5м Год назад +2

    ruclips.net/video/fGP0qoB78Nw/видео.html т.е. перед тем как отправить сообщение в брокер, мы его сохраним в бд, потом вычитаем из бд и отправим в брокер??? тогда нафига брокер спрашивается, если мы тут нагородили свою очередь? не проще ли отправлять сообщение в брокер в случае успеха транзакции в бд, а в случае ошибки отправки в брокер делать ретрай?

    • @ВладиславЛатиш
      @ВладиславЛатиш Год назад +1

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

    • @alex-0x6b
      @alex-0x6b 10 месяцев назад

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