Гарантии заказа Kafka

Я просматривал kafka документацию и наткнулся на

Гарантии

Кафка на высоком уровне дает следующие гарантии:

Сообщения, отправленные производителем в определенный раздел темы, будут добавляться в порядке их отправки. То есть, если запись M1 отправляется тем же производителем, что и запись M2, и M1 отправляется первой, то M1 будет иметь меньшее смещение, чем M2, и появится в журнале раньше. Экземпляр-потребитель видит записи в том порядке, в котором они хранятся в журнале. Для темы с коэффициентом репликации N мы допустим до N-1 отказов сервера без потери каких-либо записей, зафиксированных в журнале.

У меня было несколько вопросов.

  1. Всегда ли гарантируется, что M1 будет иметь меньшее смещение, чем M2? что, если M1 повторяется позже, чем M2?
  2. Я также понял из различных документов, что заказ не гарантируется, и покупатель должен с этим иметь дело.

apache-kafka kafka-producer-api
person Nag    schedule 09.09.2017    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Возможный сценарий даже с одним разделом:

  • Производитель отправляет M1
  • Производитель отправляет M2
  • M1 не подтверждается с первой попытки из-за некоторого сбоя
  • M2 доставлено
  • M1 будет доставлен при следующей попытке.

Один простой способ избежать этого - использовать конфигурацию производителя max.in.flight.requests.per.connection=1.

Это, конечно, влияет на производительность, поэтому его следует использовать с осторожностью.

person vahid    schedule 09.09.2017
comment
У вас есть документация или ссылки по этому сценарию? - person Josh; 28.10.2018
comment
@Josh см. retries здесь, kafka.apache.org/documentation/#producerconfigs. - person lfk; 12.06.2019
comment
@Josh Мне сказали, что это НЕПРАВИЛЬНО. Для одного раздела (в пределах той же группы потребителей) Kafka не будет пытаться доставить M2, если он не сможет доставить M1 (если M1 не истечет). - person Kashyap; 20.09.2019
comment
@Kashyap у вас есть ссылка на это? - person Josh; 23.09.2019
comment
@Kashyap продолжает, когда я перечитываю: продюсер не узнает, что M1 потерпел неудачу. Он отправит M1, затем M2, ..., MN, где N = «максимальное количество запросов на полет на соединение». M1 выбирает неправильный путь, и к тому времени, когда становится понятно, что его нужно отправить повторно, M2, ... MN уже были ACKd и отправлены. Это мое понимание одного из возможных сценариев выхода из строя. - person Josh; 30.09.2019
comment
@ Джош, ты прав. Мой оператор должен быть дополнен тем, где AUTO_COMMIT отключен. Т.е. Для одного раздела (в пределах одной группы потребителей) Kafka не будет пытаться доставить M2, если он не сможет доставить M1 (если M1 не истечет), когда AUTO_COMMIT отключен. - person Kashyap; 30.09.2019
comment
Вы также можете установить enable.idempotence = true без необходимости уменьшать max.in.flight.requests.per.connection, но вам необходимо настроить другие параметры в соответствии с документацией: Обратите внимание, что для включения идемпотентности требуется max.in.flight.requests.per .connection должно быть меньше или равно 5, количество попыток больше 0, acks должно быть «все». Если эти значения не установлены пользователем явно, будут выбраны подходящие значения. Если установлены несовместимые значения, будет выброшено исключение ConfigException. - person darshan kamat; 14.01.2021

arrow_upward
4
arrow_downward

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

Например, если вы хотите собирать сообщения от различных датчиков и у датчика есть его идентификатор, то, если вы используете этот идентификатор в качестве ключа сообщения, порядок сообщений от каждого датчика будет гарантирован для потребителей (поскольку ни один датчик не будет писать сообщения более чем на 1). раздел).

Чтобы ответить на ваши вопросы:

  1. Да, M1 всегда будет иметь смещение меньше M2. Смещения устанавливаются брокером, поэтому время прибытия сообщения брокеру является ключевым моментом.
  2. Заказ не гарантируется только на уровне темы.
person Mariusz    schedule 09.09.2017
comment
о 1) Я сомневаюсь, что это не будет гарантироваться всегда? что, если M1 прибывает позже, чем M2 или M1 сначала отказал, а затем повторил попытку позже, в то время как M2 уже прибыл? - person Nag; 10.09.2017
comment
Если M1 прибывает после M2, то он будет сохранен в порядке [M2, M1]. То же самое относится к ситуации сбоя - если ваш производитель не смог отправить M1 раньше M2, то заказ будет [M2, M1]. Kafka не сортирует сообщения, а только сохраняет их. Если вы хотите обеспечить упорядочение сообщений на стороне производителя, всегда используйте синхронный API (я имею в виду future.get() или аналогичный). - person Mariusz; 10.09.2017
comment
понятно. поэтому из stmt if a record M1 is sent by the same producer as a record M2, and **M1 is sent first** --- это гарантируется только в том случае, если брокер первым получит M1, независимо от того, отправил ли производитель M1 первым или нет. - person Nag; 11.09.2017
comment
да. Я думаю, в предложении предполагается, что вы используете синхронный API (поэтому производитель не может отправить M2, если M1 не был получен брокерами), или сообщения M1 и M2 отправляются в одном массовом сообщении (поэтому они будут сохранены в Kafka во время одного запроса) - person Mariusz; 11.09.2017

arrow_upward
0
arrow_downward

У меня есть статья о глубоком понимании гарантий заказа, предоставляемых Kafka. Вы можете проверить это на моем носителе опубликовать.

person c.guzel    schedule 12.05.2021