Прямой ответ
Брокеры сообщений ограничивают размер одного сообщения. Ограничение существует потому, что сообщение целиком помещается в память при передаче, хранении и доставке, и крупное тело умножается на число сообщений в очереди.
Порядок ограничений по умолчанию:
| Брокер | Ограничение | Настройка |
|---|---|---|
| Kafka | 1 МБ | message.max.bytes |
| NATS | 1 МБ | max_payload |
| RabbitMQ | Практически единицы МБ | Настройка канала |
| SQS | 256 КБ | Ограничение сервиса |
Увеличение лимита возможно, но влияет на всю систему: память брокера, время доставки и объём репликации растут пропорционально. Поэтому для больших данных применяется передача по ссылке.
Шаблон состоит в том, что данные помещаются во внешнее хранилище, а в сообщении передаётся ссылка:
{
"event": "report.generated",
"report_id": "r-88213",
"location": "s3://reports/2026/10/r-88213.parquet",
"size_bytes": 184320000,
"checksum": "sha256:9f2c..."
}
Тело сообщения остаётся небольшим независимо от размера данных. Получатель загружает данные по ссылке; о работе с хранилищем — в статье про presigned URL.
Три следствия подхода, которые нужно учесть.
1. Порядок записи и публикации. Данные должны быть полностью записаны в хранилище до публикации сообщения. Публикация до завершения записи приводит к чтению неполного файла.
2. Срок жизни данных. Объект должен существовать, пока возможно повторное чтение сообщения. При повторной доставке через сутки файл, удалённый через час, недоступен; о сроках — в статье про жизненный цикл объектов.
3. Согласованность. Сообщение и данные существуют отдельно, поэтому возможна ситуация, когда сообщение доставлено, а данные отсутствуют, либо наоборот. Обработчик проверяет доступность данных и не считает отсутствие необратимой ошибкой.
Контрольная сумма в сообщении позволяет проверить целостность загруженных данных и отличить повреждение от неверной версии.
Практика: работа с крупными данными в сообщениях
1. Передавайте по ссылке всё, что превышает десятки килобайт. Порог выбирается исходя из числа сообщений: при миллионах сообщений даже 100 КБ дают существенный объём.
2. Записывайте данные до публикации сообщения. Обратный порядок создаёт окно, в котором получатель читает неполные данные.
3. Устанавливайте срок хранения по времени жизни очереди. Срок хранения объекта должен превышать максимальное время до обработки сообщения, включая повторы.
4. Добавляйте контрольную сумму. Проверка после загрузки отличает повреждение данных от неверной версии.
5. Делайте загрузку повторяемой. Повторная доставка сообщения не должна приводить к ошибке из-за уже обработанных данных.
6. Не увеличивайте лимит брокера без оценки. Рост лимита увеличивает потребление памяти и время репликации для всех сообщений, а не только для крупных.
7. Обрабатывайте отсутствие данных. Объект мог быть удалён либо ещё не записан; обработчик различает эти случаи по времени публикации.
8. Логируйте размер сообщений. Метрика распределения размеров показывает рост до достижения лимита; о гарантиях доставки — в статье про надёжность доставки.
Рекомендации:
- Разделяйте событие и данные. Событие описывает, что произошло; данные хранятся отдельно. Смешение приводит к разрастанию сообщений.
- Используйте уникальные имена объектов. Перезапись объекта с тем же именем при повторной публикации делает ранее доставленные сообщения недействительными.
- Учитывайте стоимость чтения из хранилища. Каждое сообщение требует отдельного обращения к хранилищу, что при большом числе сообщений влияет на стоимость.
- Проверяйте поведение при недоступности хранилища. Обработчик должен повторять попытку, а не отбрасывать сообщение.
- Не храните в сообщении чувствительные данные. Передача по ссылке с ограниченным доступом безопаснее передачи содержимого в очереди.
Практический сценарий: отказ публикации при превышении лимита размера
Контекст: сервис формировал отчёты и публиковал событие с содержимым отчёта в теле сообщения. Для крупных клиентов публикация завершалась ошибкой.
- Диагностика. Отчёт крупного клиента занимал 180 мегабайт, а лимит брокера составлял один мегабайт. Публикация отклонялась, и событие не доходило до обработчика. Мелкие клиенты работали, поэтому проблема проявлялась только для части клиентов.
- Причина. Содержимое отчёта помещалось в тело сообщения, и размер не контролировался. Увеличение лимита брокера до 200 мегабайт потребовало бы роста памяти и замедлило репликацию для всех потоков.
- Действия. (а) Содержимое отчёта перевели на запись в объектное хранилище с передачей ссылки в сообщении; (б) запись данных выполнялась до публикации события; (в) срок хранения объектов установили в 30 дней, что превышало максимальное время до обработки; (г) добавили контрольную сумму для проверки целостности при загрузке; (д) добавили метрику распределения размеров сообщений.
- Результат. Размер сообщения перестал зависеть от размера отчёта, а публикация работает одинаково для мелких и крупных клиентов.
Вывод: передача данных по ссылке отделяет размер сообщения от размера данных и устраняет зависимость от лимита брокера. Условия корректности — запись данных до публикации и срок хранения, превышающий время до обработки.
FAQ
Какой размер сообщения считать большим? Более десятков килобайт. При большом числе сообщений даже умеренный размер даёт существенный объём хранения и репликации.
Можно ли просто увеличить лимит брокера? Технически да, но это увеличивает потребление памяти и время репликации для всех сообщений. Для единичных крупных данных передача по ссылке дешевле.
Что делать, если объект удалён до обработки? Повторная обработка невозможна, поэтому срок хранения объекта должен превышать максимальное время до обработки с учётом повторов.
Как проверить целостность данных? Контрольной суммой в сообщении. Сравнение после загрузки отличает повреждение от неверной версии объекта.
Источники: Kafka docs (message.max.bytes), AWS SQS docs (квоты сообщений), Azure Architecture Center (Claim Check) — ссылки в шапке.