Железо и софт • 06.06.2026
Apache Kafka выдает ошибку RecordTooLargeException при отправке сообщения как исправить
Развернул распределенный брокер сообщений Apache Kafka на сервере Linux для обработки потоковых данных веб-приложения. При попытке отправить тяжелый JSON-пакет данных или бинарный лог в топик со стороны продюсера (на Java/Python), мост отправки мгновенно рушится. В консоли вылетает критическая ошибка: «org.apache.kafka.common.errors.RecordTooLargeException: The request included a message larger than the max message size the server will accept». При этом стандартные мелкие сообщения обрабатываются без сбоев. Подскажите, из-за каких встроенных лимитов буфера и параметров конфигурации брокер сбрасывает сетевые пакеты и как правильно расширить лимиты на сервере и у продюсера?
Ответы (5)
Артем Кафка
Привет! Ошибка "RecordTooLargeException" — это классический тупик квотирования сетевого трафика в экосистеме Кафки. По умолчанию в конфигурации брокера установлено жесткое архитектурное ограничение: максимальный размер одного сообщения (или батча сообщений) зажат на отметке в 1 мегабайт (1048576 байт). Если твое приложение пытается пропихнуть через TCP-сокет пакет большего объема, ядро брокера мгновенно отвергает транзакцию на этапе валидации буфера. Коварство этой ошибки заключается в том, что для её исправления недостаточно просто изменить один тумблер на сервере — лимиты нужно синхронно расширять на трех разных уровнях: самого брокера, конкретного топика и клиентского продюсера.
Марина Девопс
Чтобы принудительно расширить границы приема тяжелых сообщений на стороне сервера брокера, измените параметры конфигурации строго по шагам:
1. Подключитесь к вашему серверу по SSH и откройте главный конфигурационный файл брокера через nano от имени администратора: `sudo nano /etc/kafka/server.properties`.
2. Найдите или добавьте в конец файла параметр максимального размера сообщения для брокера (например, выставим лимит в 10 мегабайт): `message.max.bytes=10485760`.
3. Ниже пропишите аналогичный лимит для размера выборки при репликации данных между внутренними нодами кластера, иначе сломается зеркалирование: `replica.fetch.max.bytes=10485760`.
4. Сохраните изменения в документе (Ctrl+O, Enter) и выйдите из редактора (Ctrl+X).
5. Принудительно перезапустите системный демон для очистки старых дескрипторов портов: `sudo systemctl restart kafka`.
Дмитрий СУБД
Ребята, помните критически важный нюанс: если вы увеличили лимит `message.max.bytes` на брокере, вам в эту же секунду нужно бежать и переписывать параметры ваших консьюмеров (consumers), которые вычитывают данные из этой очереди. Если консьюмер останется на дефолтных настройках, то при попытке забрать из топика тяжелый десятимегабайтный пакет его внутренний сетевой буфер обмена вылетит в бесконечный ступор. На стороне консьюмера в коде приложения обязательно увеличьте параметры `max.partition.fetch.bytes` и `fetch.max.bytes` до значений, равных или слегка превышающих серверный лимит.
Никита Потоки
Чтобы завершить настройку моста доставки больших пакетов, необходимо принудительно обновить лимиты конкретного топика и вашего кода продюсера по инструкции:
1. Выполните динамическое обновление лимита для вашего целевого топика через консольную утилиту без остановки кластера: `kafka-topics.sh --bootstrap-server localhost:9092 --topic my_topic --alter --config max.message.bytes=10485760`.
2. Откройте исходный код вашего приложения-продюсера (Java / Python / Go).
3. В словарь или класс конфигурационных свойств подключения (Properties) добавьте параметр максимального размера запроса.
4. Пропишите свойство: `max.request.size` со значением `10485760`.
5. Перезапустите воркеры бэкенда — сетевое рукопожатие пройдет успешно, и тяжелые JSON-логи улетят в очередь без ошибок.
Роман Архитектор
Если вам регулярно приходится гонять через брокер тяжелые медиафайлы или огромные дампы таблиц размером больше 20-50 мегабайт, раздувание конфигов Кафки — это путь к жестким просадкам производительности дисковой подсистемы ОС. Правильное архитектурное решение в таком случае — внедрение паттерна Claim Check. Продюсер сохраняет тяжелый бинарный файл во внешнее быстрое S3-облако (или MinIO), а в топик Кафки отправляет крошечное текстовое сообщение со ссылкой на этот файл и UUID. Консьюмер ловит событие, скачивает оригинал из S3 и обрабатывает его. Это полностью исключит любые ошибки переполнения буферов.