В Kafka выбор partition обычно зависит от ключа сообщения: продюсер считает хеш от key и берёт остаток по количеству partition, поэтому все сообщения с одним и тем же ключом оказываются в одном и том же partition и сохраняют порядок. Если ключ не задан, сообщения распределяются по partition по round‑robin или sticky‑стратегии, и порядок гарантируется только внутри отдельного partition. При необходимости можно настроить свой партиционер и реализовать особые правила распределения по partition.
В Apache Kafka тема разбивается на несколько partition, чтобы масштабировать обработку и параллелизм. Ключ сообщения (message key) как раз и определяет, в какой конкретный partition попадёт запись, что критично для порядка сообщений и распределения нагрузки.
Стандартное поведение продюсера Kafka:
hash(key) % partitionCount). Это значит, что все сообщения с одинаковым key всегда попадают в один и тот же partition, а внутри этого partition сохраняется порядок отправки по этому ключу. Так достигается логическая группировка, например по userId или orderId.null. В этом случае продюсер не может привязаться к какому‑то ключу и распределяет сообщения по partition равномерно: классический round‑robin или sticky‑partitioner (сериями отправляет в один partition, затем переключается). Порядок в пределах одного partition есть, но между разными partition нет, и сообщения одной логической сущности могут «разъехаться» по всем partition.Важно помнить, что при изменении числа partition в теме меняется и результат вычисления hash(key) % partitionCount, поэтому одни и те же ключи могут начать попадать в другие partition. Это не ломает Kafka как систему, но может повлиять на обработку, если вы где‑то полагаетесь на закрепление ключа за конкретным partition (например, для локального состояния).
Итого: ключ сообщения — это не просто поле, а основной механизм управления маршрутизацией по partition, гарантиями порядка по ключу и балансировкой нагрузки в кластере Kafka.
Отметьте свой прогресс