надо брать во внимание когда cleanup.policy = compact?
Тут: https://towardsdatascience.com/log-compacted-topics-in-apache-kafka-b1aa1e4665a7 довольно неплохое описание ключевых параметров
Спасибо, четенько. Но вот не увидел у него использование log.cleaner.max.compaction.lag.ms Ну или я неверно понимаю эту опцию. Поправьте если последующие утверждение не верно. Если от текущего времени отнять время создания сообщения в кафке и оно меньше чем log.cleaner.max.compaction.lag.ms и при этом есть более новое сообщение с таким же ключом то Кафка не будет удалять первое сообщение?
По сути, если верно понимаю KIP, то эта настройка как раз для того, чтобы иметь возможность удалять старые значения ключей чаще и чуть более контролируемо. По умолчанию параметр выставлен в значение long.max_value (~ что примерно эквивалентно "никогда") и сегменты будут компактиться, только если удовлятворяют min.cleanable.dirty.ratio и min.compaction.lag.ms. С log.cleaner.max.compaction.lag.ms условие меняется на такое: shouldCompact = (min.cleanable.dirty.ratio and min.compaction.lag.ms) or log.cleaner.max.compaction.lag.ms > нормальная ли практика значение ключа ставить один, но партишионер взять не murmur который хеш на основе ключа, а например на основе какого нибудь id поля из value Зависит от 🤷 Тут стоит проверить, как себя будет вести весь процесс, когда окажется, что записи с одинаковыми ключами окажутся в разных партициях из-за такого кастомного партишенера
Обсуждают сегодня