Kafka: 5 неочевидных нюансов
Всем привет. Apache Kafka кажется простой — создал топик, отправил сообщение, прочитал. Но дьявол кроется в настройках по умолчанию. Вот пять вещей, о которых часто забывают при проектировании.
1. Офсеты живут меньше, чем данные (Ловушка `offset.retention.minutes`)
Даже если сообщения хранятся неделю, подтверждения ваших консьюмеров (`офсеты`) могут удалиться уже через два дня (стандартное значение).
Как это работает: Если ваша программа долго спит (например, ночной батч), Кафка решит, что группа умерла и вычистит её координаты. При следующем запуске сервис либо начнет обрабатывать старые данные заново, либо перепрыгнет всё накопившееся и улетит в конец лога.
Решение: Держите консьюмеры «живыми» или увеличьте параметр `offsets.retention.minutes` хотя бы до нескольких дней.
2. Сообщения теряются во время старта продюсера
Когда приложение только запустилось, внутренний буфер Kafka-продюсера еще может быть не авторизован у брокера. Если отправить сообщение в этот момент, оно просто исчезнет при сетевой ошибке без явной ошибки уровня ERROR.
Решение: Отправляйте бизнес-данные только после полной готовности контекста Spring Boot (например, дождавшись события `ApplicationReadyEvent`), а для критичных данных используйте транзакции.
3. Ребалансировка останавливает всю группу
Добавили второй инстанс сервиса, чтобы стало быстрее? На несколько минут обработка полностью остановится. При классическом ребалансе все потребители сначала отдают свои партиции, коммитят офсеты и ждут перераспределения. В это время очередь растет.
Решение: Используйте современный протокол *Cooperative Rebalancing*. Он переносит партиции плавно, не отключая всех потребителей сразу.
4. Compacted-топики умеют удалять данные (*Tombstones*)
В компактированных топиках можно передать `null` вместо значения. Это специальный маркер удаления (Tombstone). Ключ физически исчезнет из топика только через сутки (параметр `delete.retention.ms`). Всё это время любой потребитель будет получать пустой результат и ловить `NullPointerException`.
Решение: Тщательно проверяйте DTO перед отправкой. Запретите сериализацию null-полей, если используете JSON.
5. Успешный ответ `.send()` не гарантирует запись на диск
Ваш продюсер получил подтверждение от Кафки? Это значит, что данные попали в оперативную память сервера (Page Cache), но не обязательно на физический диск. При внезапном выключении питания ноды последние записи пропадут даже при `acks=all`.
Решение: Для действительно важных данных настраивайте принудительный сброс кэша на диск (`log.flush.interval.messages`) и всегда помогут сделать вашу систему надежнее.