Типичные ошибки и антипаттерны

Урок-чеклист: собираем главные грабли Kafka в одном месте, чтобы не наступать на них в проде.

Большинство проблем с Kafka — не баги платформы, а предсказуемые ошибки конфигурации и дизайна: неверное число партиций, плохой ключ, тяжёлые сообщения, неаккуратные гарантии.

Зачем это нужно

Kafka прощает многое, пока нагрузка мала. Грабли всплывают на масштабе — и сразу больно. Зная их заранее, вы закладываете правильные решения с самого начала, а не переделываете прод под пожаром.

Карта типичных ошибок

Ошибка	Симптом	Лечение
Мало партиций	низкий потолок параллелизма, консьюмеры простаивают	оценить нагрузку, заложить партиции с запасом
Тяжёлые сообщения	раздутая память, лаг, давление на сеть	блоб в хранилище, в Kafka — ссылку
Неверный ключ	hot partition или потеря порядка	ключ высокой кардинальности, но удерживающий порядок сущности
Долгая обработка в poll	ребаланс-штормы, растущий лаг	меньше max.poll.records, вынести работу из poll
acks=1 / RF=1	потеря данных при сбое	acks=all, RF=3, min.insync.replicas=2
Сырой JSON без схемы	ломающие изменения формата в проде	Schema Registry, совместимая эволюция

Мало партиций

Создали топик с 1-2 партициями «на старте» — и упёрлись в потолок: сколько консьюмеров ни добавляй, читают только 1-2. Увеличить число партиций потом можно, но это ломает порядок по ключу. Оценивайте пиковую нагрузку заранее и закладывайте запас.

Тяжёлые сообщения и неверный ключ

Сообщения по мегабайту раздувают батчи, память продюсера/брокера и лаг. Крупные данные (картинки, документы) кладите в S3/MinIO, а в Kafka передавайте ссылку и метаданные. Неверный ключ — вторая классика: ключ status или country с парой значений создаёт hot partition; отсутствие ключа теряет порядок связанных событий.

Ребаланс-штормы и слабые гарантии

  Антипаттерн "тяжёлый poll":
    poll() -> 5000 записей -> обработка 2 минуты -> исключение из группы
    -> ребаланс -> снова poll -> снова исключение -> ШТОРМ

  Лечение: max.poll.records поменьше, обработка быстрее/асинхронно,
           heartbeat в отдельном потоке (современные клиенты так и делают)

Как работает под капотом

Почти все эти грабли — следствие того, что мы уже разобрали по частям. Партиции — единица параллелизма, поэтому их нехватка жёстко ограничивает масштаб. Ключ определяет партицию и порядок, поэтому его выбор балансирует равномерность и упорядоченность. Гарантии (acks/RF/ISR) — это явный компромисс скорость-против-надёжности, и «по умолчанию быстро» часто значит «по умолчанию небезопасно». Понимание механики из предыдущих разделов превращает этот список из набора суеверий в осознанные инженерные решения.

Частые ошибки

Тюнить по советам из интернета без понимания. Параметры взаимосвязаны; меняйте осознанно, измеряя эффект.
Один топик «на всё». Разные типы событий с разными требованиями к retention/партициям лучше разнести.
Игнорировать обратное давление. Если потребитель не успевает, лаг растёт — нужно масштабировать чтение, а не «надеяться».

Итоги

Главные грабли: мало партиций, тяжёлые сообщения, плохой ключ, тяжёлый poll, слабые гарантии.
Лечатся осознанным дизайном: запас партиций, ссылки вместо блобов, правильный ключ, acks=all/RF=3.
Список перестаёт быть суеверием, когда понимаешь механику партиций, ключей и гарантий.