7 ошибок при использовании Apache Kafka

Во-первых, давайте определим нижнюю границу. Количество partitions определяет максимальное количество consumers в одной consumer group. Если мы определим слишком маленькое число, то partitions будут расположены не на всех брокерах, что приведет к неравномерной загрузке кластера. Это означает, что максимальная скорость потребления сообщений и скорость генерации сообщений в топике зависят от количества partitions в топике.

Большое количество partitions влияет на различные процессы. Publishers буферизируют сообщения, отправляемые в Kafka, для каждого partition отдельно. Большее количество partitions означает меньшую вероятность того, что сообщения с разными ключами попадут в один и тот же partition, это означает меньшую вероятность неравномерной загрузки partition. Кроме того, больше partition = больше отдельных буферов = больше потребляемой памяти

Со стороны broker больше partitions означает большее количество открытых файловых дескрипторов. С другой стороны, у каждого partition есть лидер, которого выбирает Kafka Controller. Если одновременно необходимо выбрать несколько новых лидеров (например, из-за сбоя брокера), то контроллер может принимать "решения" с большой задержкой, а разделы могут быть недоступны в течение длительного времени. Например, процесс выбора лидера для 1000 partitions занимает около 5 секунд

Допустим, вы решили установить некоторое количество "временных" partitions и позже изменить их размер. Однако partition по умолчанию для сообщений с заданным ключом вычисляет хэш от ключа по модулю количества partitions. Когда количество разделов изменится, то сообщения с тем же ключом могут начать помещаться в другой partition. Такое изменение может привести к изменению порядка сообщений (для заданного ключа) при изменения количества partitions для топика

Так какое же число является оптимальным? Чтобы это понять, следует провести несколько тестов производительности. Смоделируйте нагрузку, подключите consumers и проверьте, какое количество partitions позволит достичь необходимой производительности

Java-клиент Kafka является довольно мощным, но у него не лучший API. Использование Java Consumer может доставлять неудобства. Во-первых, класс Kafka Consumer может использоваться только одним потоком. Затем необходимо определить вечный цикл, который будет опрашивать брокер на наличие сообщений. Однако самым важным является то, как работают таймауты и heartbeats

За heartbeat отвечает дополнительный поток, он периодически посылает сообщение брокеру, чтобы показать, что он работает. Для Kafka нужно еще кое-что. Настройка max.poll.interval.ms (по умолчанию 5 минут) определяет максимальное время между hearbeats. Если оно будет превышено, то consumer будет исключен из consumer group. Это очень важно! Допустим, вы потребляете сообщения и отправляете их какому-то внешнему REST API. В случае неудачи отправки вы можете использовать экспоненциальный откат. Если пройдет более 5 минут, то ваш consumer покинет consumer group, а сообщение будет доставлено другому consumer из этой же consumer group. Самый простой способ избежать такого сценария - ограничить количество сообщений, получаемых за один вызов

Обычно, когда вы спрашиваете своего клиента, какая семантика доставки приемлема для него, вы, разумеется, слышите ответ: ровно один раз. Затем вы немного гуглите и увидите замечательные заголовки, утверждающие, что Kafka поддерживает семантику exactly once! Отчасти это правда, но с теоретической точки зрения не существует такой вещи, как exactly once delivery...

В случае с Kafka (как и с любой другой распределенной системой) существуют ограничения на exactly once. Нужно включать специальные настройки на стороне producer (например, enable.idempotence, который требует определенных значений для max.in.flight.requests.per.connection, retries и acks). На стороне сonsumer это сложнее. Из-за сбоев передачи сообщений, падения consumer можно получить сообщение более одного раза, и тогда придется заниматься дедупликацией на уровне consumer. Что в любом случае приводит нас к идемпотентному consumer