Ключи и порядок сообщений

В kafka.Message поле Key — срез байтов рядом с Value, и разница между ними принципиальная: Value — полезная нагрузка, которую читает консьюмер, Key — служебный маршрут, по которому решается партиция. Kafka ключ не хранит для поиска и не индексирует: он нужен в момент записи, чтобы продюсер выбрал партицию, и консьюмеру в конце концов виден как метаданные. Связь «kafka ключ партиция» проста: одинаковый ключ всегда попадает в одну и ту же партицию топика, сколько бы сообщений с ним ни отправили. А раз события лежат в одном журнале подряд, порядок их обработки гарантирован: партиция — append-only лог, читатель идёт по оффсетам и видит записи ровно в том порядке, в каком их дописали. Отсюда правило выбора ключа уровня архитектуры: ключом становится идентификатор сущности, внутри которой важна последовательность — заказ, аккаунт, устройство, сессия. Не пользователь в целом, если порядок нужен по его заказам, и не случайное число — иначе вы получите перемешанный поток, ради которого Kafka и не начинали. Вопрос «а если ключей миллионы» отводится просто: партиций конечное число, хэш оседлит ключи по ним, и ограничений на количество уникальных ключей нет.

Балансировщик kafka.Hash в kafka-go делает ровно одну вещь: считает от байтов ключа хэш FNV-1a и берёт остаток от деления на число партиций — полученный индекс и есть адрес записи. Всё детерминированно: тот же ключ, тот же набор партиций — тот же индекс, без обращений к брокеру и без состояния между вызовами. Хэш FNV-1a выбран не случайно: он быстрый, редко даёт коллизии на коротких ключах вроде order-42 и в среднем распределяет произвольные ключи по партициям равномерно. Слово «в среднем» — важная оговорка: хэш равномерен по множеству ключей, а не по вашему трафику. Пять ключей из тысячи могут принадлежать одному мегаклиенту, и его партиция получит непропорциональную нагрузку — классическая горячая партиция, симптомы которой ловят мониторингом записи по партициям. Из механики хэша следуют и два практических правила: число партиций входит в формулу, поэтому его изменение сдвигает все индексы разом — об этом коллаут ниже; а предсказать партицию по ключу «на глаз» невозможно и не нужно — считайте, что распределение честное, пока мониторинг не показал обратное. Проверить перекос на живом топике легко: печать m.Partition по сотне сообщений или счётчики продюсера по партициям покажут его раньше, чем он станет инцидентом.

Соберём гарантию точно, без маркетинга. Продюсер дописывает сообщения в конец партиции, брокер выдаёт им монотонные оффсеты, консьюмер читает партицию последовательно: сумма этих трёх шагов и называется порядком сообщений kafka — внутри одной партиции он абсолютный. Всё, что вне партиции, порядок не образует: две партиции читаются параллельно двумя консьюмерами, и ни брокер, ни клиент не скажут, какое событие «раньше». Поэтому порядок в Kafka всегда проектируют, а не получают: определить сущность, внутри которой нужна последовательность; выбрать её идентификатор ключом; проверить, что все продюсеры этих событий используют Hash-балансировщик с тем же ключом. И принять цену: единица порядка становится единицей параллелизма — все события аккаунта упираются в одну партицию и обрабатываются одним консьюмером группы, сколько бы инстансов ни было развёрнуто. Если сущность с постоянным потоком событий одна и та же — узкое место уже не в партициях, а в модели: возможно, события стоит дробить по под-сущностям или отдавать порядок на согласование самой базе. Это не поражение, а нормальная эволюция: многие команды начинают с одного ключа и позже выделяют внутри сущности подпотоки — например, по типу события, — когда параллелизм становится важнее общего порядка.

RoundRobin — балансировщик по умолчанию и второй полюс выбора: он крутит сообщения по партициям по кругу, не глядя на содержимое. Нагрузка получается максимально ровной, но одинаковые ключи разъезжаются по разным партициям — и никакого порядка по сущностям больше нет. У kafka.Hash есть важный запасной ход: если у сообщения нет ключа, балансировщик отдаёт его в RoundRobin-ветку. То есть с Balancer: &kafka.Hash{} вы получаете порядок для сообщений с ключами и ровность для сообщений без них — удобная смесь для топиков, где события с телеметрией соседствуют с событиями домена. Что класть без ключа? Всё, где порядок не имеет смысла: метрики, пинги, разовые нотификации. А вот события, которые консьюмер сравнивает или складывает в состояние, обязаны идти с ключом — иначе два экземпляра одной сущности обработаются параллельно, и гонка вернётся уже на стороне читателя. Выбор между RoundRobin и Hash — не вкусовщина: это выбор между ровной нагрузкой и порядком, и смешивать их в одном ключе-поле хуже, чем держать по балансировщику на топик. Отдельный бонус RoundRobin: он не требует держать в голове домен — быстро, ровно и предсказуемо, поэтому для служебных потоков остаётся разумным умолчанием.

Число партиций — решение, которое принимается до первого сообщения и потом стоит денег. Сверху партиции ограничивают параллелизм чтения: больше потребителей в группе, чем партиций, — лишние простаивают, и масштабирование упирается в потолок. Снизу — тоже не бесплатные: каждая партиция — открытые файлы, индексы и участие в репликации, а сотни партиций на топик усложняют ребалансировку и выборы лидеров. Практический ориентир для сервисного топика — единицы-десятки партиций: три-шесть для событий с умеренным потоком, десяток-другой для горячих каналов; топики под сотни тысяч событий в секунду проектируют от измеренной скорости одного консьюмера. План на рост честнее всего такой: заложить запас на год, считать ключи и порядок контрактом, а увеличение партиций проводить как миграцию — с остановкой записи или перечитыванием, потому что индексы сдвигаются. Управление топиками из кода — CreateTopics и Admin API — вернётся в шестнадцатом уроке, там же про то, как менять конфигурацию партиций осознанно. И запишите решение о числе партиций в ADR: через год никто не вспомнит, почему их было шесть, а спорить с числом без контекста — любимое развлечение архитектурных ревью.