Группы потребителей Kafka внезапно перестали балансировать сообщения между экземплярами - PullRequest
Новая
       18

Группы потребителей Kafka внезапно перестали балансировать сообщения между экземплярами

1 голос
/ 15 мая 2019

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

Например: 

SERVICE_A_INSTANCE_1 (CONSUMER_GROUP_A)
SERVICE_A_INSTANCE_2 (CONSUMER_GROUP_A)
SERVICE_A_INSTANCE_3 (CONSUMER_GROUP_A)

SERVICE_B_INSTANCE_1 (CONSUMER_GROUP_B)
SERVICE_B_INSTANCE_2 (CONSUMER_GROUP_B)

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

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

Важные моменты:

  • Мы используем Kafka Paas в Confluent на GCP.
  • Мы проверили это в другой среде, и все заработало как положено
  • На наших потребителях изменений не было
  • С нашей стороны в кластер не было внесено никаких изменений (мы не можем знать, изменил ли Confluent что-либо)

Мы подозреваем, что это может быть проблема на Confluent или обновление, которое не совместимо с нашей текущей конфигурацией. Kafka 2.2.0 был недавно выпущен и в нем есть некоторые изменения в поведении групп потребителей.

В настоящее время мы работаем над переходом на AWS MSK, чтобы выяснить, существует ли проблема.

Есть идеи о том, что может быть причиной этого?

1 Ответ

0 голосов
/ 30 июня 2019

TL; DR: Мы решили эту проблему, переместившись из Confluent в наш собственный кластер Kafka на GCP.

Я отвечу на свой вопрос уже давно, и мы уже решили это. Кроме того, мои идеи могут помочь другим принимать более обоснованные решения о том, где развернуть свою инфраструктуру Kafka.

К сожалению, мы не смогли разобраться в проблеме с Confluent. Скорее всего, это что-то на их стороне, потому что мы просто мигрировали в свои собственные управляемые экземпляры в GCP, и все вернулось в норму.

Несколько важных разъяснений перед моими последними мыслями и предупреждениями об использовании Confluent в качестве управляемого сервиса Kafka:

  • Мы думаем, что это связано с чем-то, что в особенности повлияло на Node.js. Мы протестировали внешние библиотеки на языках, отличных от Node, и поведение было таким, как ожидалось. При тестировании на нескольких самых популярных библиотеках Node проблема сохранялась.
  • У нас не было премиальной поддержки с Confluent.
  • Я не могу подтвердить, что эта проблема не по нашей вине.

Учитывая все эти моменты, мы пришли к выводу, что для компаний, решивших использовать управляемый сервис с Confluent, лучше всего рассчитывать затраты с включенной премиум-поддержкой. В противном случае Кафка превращается в полностью закрытый черный ящик, что делает невозможным диагностирование проблем. По моему личному мнению, зависимость от команды Confluent во время проблемы настолько велика, что отсутствие готовности к оказанию помощи в случае необходимости делает службу не готовой к работе.

...