Этот пост - небольшой конспект доклада с Highload Кафка. “Описание одной борьбы” / Денис Карасик (Badoo). Как ясно из заголовка статьи, здесь будет рассказано о некоторых важных параметрах конфигурации брокеров, топиков и producer’ов

Важные Параметры

Конфигурация брокеров

Одинаковая производительность брокеров

Когда producer пишет в partition, то он пишет в ту реплику, которая является лидером для этого partition. Consumer также читает данные с этого лидера, однако только что записанное сообщение не будет сразу доступно для чтения consumer’ам. Все остальные брокеры должны его себе среплицировать (конечно, зависит от replica factor), и только потом сообщения будет доступно для чтения.

К чему это приводит? Скорость кластера зависит от скорости самого медленного брокера, поэтому все брокеры должны иметь одинаковую производительность и иметь между собой быстрое сетевое соединение

Частота проверки новых данных

replica.fetch.wait.max.ms - в самом докладе и много где на просторах интернета говорят, что это по сути параметр, который регулирует частоту запросов новых сообщений с лидера. Однако в документации он описан как max wait time for each fetcher request issued by follower replicas, что скорее означает, что это максимальное время ожидания ответа от лидера при запросе данных со стороны реплики

Максимально допустимое отставание реплики от лидера

replica.lag.time.max.ms - максимальный промежуток временени, в течение которого реплика не просто должна прислать запрос на получение новых данных, но и также забрать свежие сообщения. Если реплика не успевает, то она исключается из списка ISR (in-sync replicas)

Конфигурация producer’ов

Разумная настройка acks на стороне producer’а

Когда producer пишет данные в kafka, он может ожидать подтверждения записи этих данных не только лидером, но и всеми остальными репликами. Что и говорить о том, как это важно для критичных данных.

(acks = acknowledgments)

acks = 0 (none) Не ждать подтверждения о записи

acks = 1 (leader) Ждать подтверждения о записи лидером (не ждать запись на реплики) Если сообщение записалось на лидера, а тот упал, когда данные не успели среплицироваться на реплики, то так можно и потерять данные

acks = -1 (all) Ждать запись и на лидера, и на все реплики. Важное замечание - подтверждение ожидается только от in-sync реплик, поэтому также важно задать, сколько минимально живых реплик нам требуется, чтобы запись считалась успешной (см конфигурацию топиков)

Конфигурация топиков

Минимальное количество in-sync реплик, подтверждающих успешную запись

Если acks для producer выставлен в -1, то параметр min.insync.replicas задаёт, от скольки минимум in-sync реплик (включая лидера), требуется подтверждение записи, чтобы запись считалась успешной.

Например, в случае, если для топика заданы 3 реплики (replication factor), а min.insync.replicas = 1, то может случиться ситуация, когда 2 реплики рассинхронизируются, в списке ISR останется только один лидер, который будет продолжать подтверждать успешную запись данных. Это всё равно, что задать acks = 1.

ISR (in-sync replica)

Список всех “живых” реплик, который ведётся отдельно для каждого partition. Если репликация на реплике сильно отстаёт (устанавливается параметром replica.lag.time.max.ms) от лидера, то реплика исключается из списка ISR.