#apache-kafka #kafka-consumer-api #apache-kafka-streams #spring-kafka
Вопрос:
Опубликуйте этот вопрос, чтобы обсудить лучшие подходы/практики для масштабирования потребителей кафки. Вот мой пример использования —
У нас есть несколько (более миллиона) приложений, отправляющих данные в кафку — каждому приложению назначена одна тема кафки с шестью разделами. Нам нужно обрабатывать данные, передаваемые приложениями, почти в режиме реального времени-нам нужно выполнить обратный вызов после завершения обработки, и это должно быть в соответствии с записью кафки. Таким образом, наивный подход состоит в том, чтобы создать одного потребителя кафки на раздел. Но это может дорого обойтись, особенно когда некоторые приложения не создают данные в непрерывной последовательности. Поэтому, чтобы решить эту проблему, мы решили создать потребителей, подписывающихся на несколько тем (шаблон соответствия регулярному выражению spring-kafka) — у нас может быть произвольное количество потребителей, подписавшихся на темы, и пусть платформа kafka обрабатывает распределение разделов среди доступных потребителей; все потребители будут принадлежать к одной уникальной группе потребителей.
Этот подход, по-видимому, работает при нормальной рабочей нагрузке/структуре трафика, но есть некоторые очевидные недостатки, которые мы хотели бы устранить —
- Один медленный потребитель потенциально может повлиять на общее отставание потребителей, особенно когда обработка записей варьируется от приложения к приложению, а потребители подписываются на несколько тем.
- Стратегии увеличения/уменьшения масштаба.
- Индивидуальная проверка здоровья потребителей — идентификация зомби ?
Комментарии:
1.
One slow consumer can potentially affect overall consumer lag— какова ожидаемая продолжительность обработки, несколько миллисекунд, секунд или минут? вам нужно обрабатывать сообщения о потребителе из разных тем одним и тем же способом или по-разному? нет необходимости запускать новый экземпляр приложения на стороне потребителя для каждого раздела, вместо этого используйте следующие свойства:num.stream.threadsдля потоков кафки илиconcurrencyдля spring-кафки, чтобы параллельно потреблять2. У нас есть этот вариант использования добавления экспоненциального отступления при повторных попытках. Поэтому, когда обработка записи завершается неудачно, мы перенаправляем ее в другую тему, и потребителю темы-2 необходимо обработать ее с некоторым отступом (вычислить разницу во времени между отметкой времени публикации сообщения и текущей отметкой времени). Ну, на самом деле мой вопрос заключается в том, как настроить параметры параллелизма.
3. Один из вариантов состоит в том, чтобы иметь отдельный набор потребителей для каждого типа обработки(медленный/быстрый), а затем получить пользовательскую метрику, такую как вычисление задержки с точки зрения дельты времени обработки сообщений между отметкой времени публикации записи и отметкой времени текущей системы. Затем мы можем использовать эту метрику для масштабирования независимых групп потребителей.
4. Как вы планируете управлять смещениями/дубликатами записей этих независимых групп потребителей? Это не решит никаких проблем с задержкой и эффективно приведет к DDOS-атаке на нижестоящие службы. Если разные группы представляют собой разные наборы тем, вам все равно нужно будет каким-то образом «передавать» состояния подписки и номера смещений этим группам по мере масштабирования
5. Извините, я думаю, что мой комментарий был неясен. Наша обработка варьируется от темы к теме. Например, группы потребителей, подписавшиеся на темы, требующие обработки с отсрочкой, будут продвигаться более медленными темпами, чем те группы потребителей, которые обрабатывают без какой-либо отсрочки. Можно получить пользовательские показатели задержки для каждой группы потребителей. Затем мы можем использовать эти показатели для масштабирования, возможно ?