Публикация: PublishWithContext

Сигнатура ch.PublishWithContext(ctx context.Context, exchange, key string, mandatory, immediate bool, msg amqp.Publishing) error умещает отправку в один вызов, и каждый аргумент здесь смысловой. Exchange — обменник, в который уходит сообщение; пустая строка означает дефолтный обменник, который маршрутизирует по имени очереди, поэтому первые примеры курса публикуют с exchange равным пустой строке и ключом tasks. Key — routing key: для дефолтного обменника это буквально имя очереди, для остальных — слово, по которому обменник сопоставляет привязки; разбор обменников по типам начинается в одиннадцатом уроке. Mandatory — просьба вернуть сообщение, если маршрута не нашлось; этому флагу ниже посвящён отдельный раздел. Immediate — исторический флаг: поддержка удалена из брокера ещё в релизе 3.0, true приводит к ошибке канала, поэтому в современном коде передают false. Msg — структура amqp.Publishing с телом и заголовками. Контекст ограничивает время ожидания отправки: если соединение заблокировано и кадр не уходит, вызов вернётся по дедлайну вместо вечного зависания. Возвращает вызов error — и почти во всех обстоятельствах nil, к чему вернёмся сразу после кода.

Самое частое заблуждение про rabbitmq publish: nil из PublishWithContext принимают за гарантию доставки. На самом деле nil означает, что сообщение покинуло библиотеку и ушло брокеру по сети. Дошло ли оно до очереди, легло ли на диск, забрал ли потребитель — из этого nil не следует ни первое, ни второе, ни третье. Маршрута нет — брокер по умолчанию молча выбрасывает сообщение, и это не ошибка: публикация вернёт nil. Брокер перезапустился вместе с недолговечной очередью — nil возвращён задолго до аварии, продюсер ни о чём не догадался. Для честных гарантий у протокола есть два отдельных механизма: mandatory, который возвращает сообщение, если маршрутизация не сработала, и publisher confirms — подтверждения брокера о приёме публикации, отдельный режим канала; к confirms курс вернётся, когда займётся устойчивостью к сбоям. Сейчас важно приучиться читать nil как «отправлено», а не «доставлено»: разница между этими словами на продакшене измеряется днями расследований.

Структура amqp.Publishing описывает сообщение целиком, и тело здесь лишь одно из полей. Body — это []byte: библиотека не сериализует ничего сама, строка, JSON или protobuf — ваша забота, а форматирование структур через JSON разберём в пятнадцатом уроке. ContentType подсказывает потребителю формат: text/plain для простых строк, application/json для структур — потребитель ветвится по нему, не заглядывая внутрь. Headers — карта amqp.Table для произвольных атрибутов: идемпотентные ключи, версия схемы, идентификатор трассировки из внешней системы. DeliveryMode определяет долговечность сообщения — единица против двойки, полный разбор в девятом уроке. Expiration задаёт срок жизни в миллисекундах строкой, Priority — приоритет для очередей с поддержкой приоритетов. Поля CorrelationId и ReplyTo пока просто запомните: на них держится RPC над очередями из восемнадцатого урока. Практическое правило: данные, по которым строят маршрутизацию и фильтрацию, выносят в заголовки и routing key, а тело держат компактным — большие файлы в очередь не кладут.

Флаг mandatory=true меняет поведение брокера для немаршрутизируемых сообщений: вместо молчаливого выброса он отправляет их обратно продюсеру методом basic.return. В amqp091-go возвраты приходят на канал, который регистрируется вызовом ch.NotifyReturn: метод возвращает chan amqp.Return, и читать его нужно в отдельной горутине — возврат асинхронный, к моменту возврата PublishWithContext уже вернул nil. Внутри amqp.Return лежит тело сообщения и поля протокола: ReplyText с причиной no-route, исходный routing key, имя обменника. Отсюда минимальная дисциплина продюсера: публиковать с mandatory=true в критичных местах и логировать каждый возврат как ошибку уровня alert. Отдельно про настоящие ошибки: публикация в несуществующий именованный обменник — это не возврат, а 404 NOT_FOUND, брокер закрывает канал, и ошибка всплывает в PublishWithContext обычным error. Дефолтный обменник с пустым именем существует у брокера по определению, поэтому до этого урока ошибки 404 у вас и не встречались.

Публикация разделяет судьбу канала: PublishWithContext нельзя дёргать из нескольких горутин на одном канале — кадры перемешаются, и брокер закроет канал; правило одного канала на горутину из четвёртого урока действует и здесь. В HTTP-обработчике контекст удобно брать от запроса: клиент отвалился — уходит и отправка. Но есть нюанс, на котором спотыкаются: обрыв соединения пользователем — сомнительный повод терять задачу, поэтому для критичных публикаций я завожу отдельный контекст с дедлайном, независимым от запроса. Спорить можно о том, что правильнее для вашего трафика, но терять заказ из-за закрытой вкладки браузера мне не нравится. Второй нюанс — размер: сотня килобайт на тело обычно безболезненна, а десятки мегабайт превращают очередь в файловое хранилище и съедают пропускную способность; файл кладите в объектное хранилище, а в очередь — ссылку. Третий — дедупликация: при повторных отправках после сбоя потребитель получит копию, и бизнес-ключ в заголовках спасает от двойной обработки.