Сообщения, отправленные на REST-прокси Kafka, отклоняются из-за ошибки «Этот сервер не является лидером для данного раздела»

Question

Мы столкнулись с некоторыми проблемами и разным пониманием между командой разработчиков и командой поддержки среды в отношении rest-прокси Kafka с конфлюэнтной платформы.

Прежде всего, у нас есть среда 5 брокеров Kafka , с 64 разделами и с коэффициентом репликации 3 .

Случается, что все наши вызовы rest-proxy сейчас используют следующую структуру:

curl -X POST \
  http://somehost:8082/topics/test \
  -H 'content-type: application/vnd.kafka.avro.v1+json' \
  -d '{  
   "value_schema_id":1,   
   "records":[  
      { "foo":"bar" }]}'

Этот тип вызова работает для 98,4% вызовов, и я заметил, что когда я пытаюсь сделать этот вызов более 2 000 раз, мы не получаем никакого ответа OK из раздела 62 (в точности 1,6% перегородок). Раньше этот коэффициент ошибок составлял 10,9% , когда у нас было 7 разделов, возвращавших ошибки прямо перед тем, как служба поддержки рециркулировала схему-реестр.

Теперь, когда вызов переходит на раздел 62, мы получаем следующий ответ:

{
    "offsets": [
        {
            "partition": null,
            "offset": null,
            "error_code": 50003,
            "error": "This server is not the leader for that topic-partition."
        }
    ],
    "key_schema_id": null,
    "value_schema_id": 1
}

Ошибка такая же, когда я пытаюсь отправить сообщения на определенный раздел, добавив "/ partitions / 62" в URL.

Служба поддержки говорит, что rest-proxy недостаточно умен ( «это просто прокси» *, говорят, 1026 *), чтобы выбрать правильный раздел и опубликовать его в ведущем брокере этого раздела. Они сказали, что он случайным образом выбирает раздел, а затем случайным образом выбирает посредника для публикации (что может привести к публикации на репликах или даже посредникам, у которых нет раздела). Они рекомендовали нам изменить наши вызовы, чтобы получить метаданные темы, прежде чем публиковать сообщения, а затем сообщить об этом разделу и посреднику и обработать циклическое назначение на стороне приложения, что для меня не имеет смысла.

Что касается разработки, то я понимаю, что rest-proxy использует apache kafka-client для отправки сообщений посредникам и, таким образом, достаточно умен, чтобы отправлять сообщения ведущему посреднику в данный раздел, а также обрабатывает Робин внутри библиотеки kafka-client, когда раздел не сообщается. Мне кажется, что проблема среды связана с этим разделом, а не с самим приложением вызова (так как оно работает без проблем в других средах с такой же конфигурацией).

Подводя итог, мои вопросы:

1. Правильно ли я говорю, что rest-proxy достаточно умен, чтобы обрабатывать циклический перебор раздела и отправлять сообщения лидеру?
2. Должно ли приложение обрабатывать логику в вопросе 1? (Я не вижу причины для использования rest-proxy вместо kafka-client напрямую в этом случае)
3. Вам это тоже кажется проблемой в оркестровке среды?

Надеюсь, вам стало ясно, что вы мне поможете!

Заранее спасибо!

Answer 1

Я не использую rest-proxy, но эта ошибка скорее всего указывает на то, что NotLeaderForPartitionException происходит во время звонков. Эта ошибка указывает, что лидер раздела изменился, но производитель все еще использует устаревшие метаданные. Эта ошибка произошла со мной, когда репликация между брокерами не удалась из-за внутренней ошибки на сервере Kafka. Это можно проверить в журналах сервера.

В нашем случае я проверил тему с помощью ./kafka-topics.sh --describe --zookeeper zookeeper_ip:2181 --topic test, и она показала, что реплики одного брокера не синхронизированы (столбец ISR). Помог перезапуск этого посредника, реплики стали синхронизированы и ошибка исчезла.