Кафка согласование работы / офсета с потребителем

В настоящее время я пытаюсь разработать масштабируемую потребительскую архитектуру для kafka, и у меня возникают некоторые проблемы с координацией смещения. Для моего варианта использования важно, чтобы каждое сообщение, потребляемое kafka, обрабатывалось ровно один раз.

Для иллюстрации проблемы возьмем следующее:

  1. Потребитель получает сообщение от Kafka
  2. Сообщение о потребительских процессах (бизнес-логика, ура!)
  3. Потребитель завершает обработку, увеличивает локальное смещение
  4. Потребитель пытается передать компенсацию обратно в kafka
  5. Этот сетевой вызов завершился неудачно по X причине
  6. Вышеупомянутая ошибка или что-то еще вызывает сбой потребителя до того, как можно будет повторить фиксацию смещения.
  7. Системный оркестратор вызывает другого потребителя, который затем извлекает устаревшее смещение.
  8. То же сообщение извлекается и повторно обрабатывается (плохо!)

Те, у кого больше опыта в работе с распределенными системами, чем я, вы, вероятно, осознали, что это (более или менее) проблема двух генералов, применяемая к координации смещения / результатов работы Kafka.

Я думал о фиксации смещения и результат работы в транзакции (возможно, SQL) db, но это связывает эти реализации вместе, а также ограничивает мои параметры хранилища данных (а также, что мне делать, если я перемещаю свое хранилище данных во что-то без транзакций ?). Другое возможное решение - хеширование каждого сообщения и использование фильтров Блума для вероятностного предотвращения дублирования обработки, но теперь мы начинаем добавлять сложность, которой я бы предпочел избежать.


person pdeuchler    schedule 11.04.2016    source источник


Ответы (1)


Подобные проблемы характерны для границ между системами и FAQ Kafka предлагает использовать транзакции для обеспечения гарантии одноразовой доставки.

Вы выразили обеспокоенность тем, что необходимость в транзакциях ограничит выбор хранилища решениями SQL. Это неправда, поскольку многие решения NoSQL, такие как Riak, Cassandra, RethinkDB или CockroachDB, имеют такие механизмы, как атомарные операции с одним документом или операции сравнения и установки, которые можно использовать как замену транзакциям ACID или как основу для клиентской стороны. ACID транзакции.

Дополнительную информацию см. В вопросе Как управлять транзакциями в нескольких базах данных. поскольку алгоритмы транзакций с несколькими шардами отлично работают и на уровне нескольких ключей.

person rystsov    schedule 26.04.2016