Сначала уточните брокер. Для обычной consumer group Kafka события одной сущности направляют в одну partition стабильным ключом, например account_id. Timestamp в ключе может разнести их по разным partition. При ребалансировке нужны корректные остановка обработки и commit offset; один ключ не предотвращает повторы и не гарантирует порядок внешних побочных эффектов.
Какой ключ помогает сохранить порядок событий при ребалансировке потребителей?
Ключ бизнес-сущности, порядок внутри partition и управление незавершённой обработкой. Почему timestamp в ключе может разрушить нужную группировку.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Если вопрос относится к вашему проекту, назовите фактический брокер и ключ. Универсального ключа «для любой ребалансировки» нет.
В обычной consumer group Kafka порядок определяется внутри partition. Чтобы связанные события попадали туда последовательно, часто выбирают стабильный идентификатор бизнес-сущности: счёта, заказа или пользователя — в зависимости от нужной области порядка. Поведение partitioning и consumer position описано в документации Kafka.
Добавление timestamp или нового случайного ID в ключ может разнести события одного пользователя по разным partition. Порядковый номер события полезен для проверки пропусков и устаревших изменений, но это отдельное поле, не обязательная часть ключа маршрутизации.
Ребалансировка меняет владельца partition, а не её логический порядок. Однако незавершённые операции старого потребителя и работа нового могут пересечься вне брокера. Нужны управление обработкой при отзыве partition, корректный commit offset, идемпотентность и при необходимости проверка версии либо fencing во внешнем хранилище.
Параллельная обработка внутри потребителя также может переставить завершение событий. Изменение количества partition требует отдельного плана, поскольку отображение ключа может измениться.
Не обещайте глобального порядка между всеми partition. Сначала зафиксируйте, для каких именно событий и на каком этапе он требуется.