Очередь: QueueDeclare и свойства

Сигнатура ch.QueueDeclare(name string, durable, autoDelete, exclusive, noWait bool, args amqp.Table) умещает политику очереди в один вызов, поэтому разбор queuedeclare go стоит начинать с возвращаемого значения. Функция возвращает Queue с тремя полями: Name — как очередь названа на сервере, что важно при пустом имени; MessageCount — сколько сообщений готово к доставке прямо сейчас; ConsumerCount — сколько потребителей подписано. Оговорка честности: счётчики достаются бесплатно только потому, что объявление заодно запрашивает состояние; при noWait брокер ответа не шлёт, и поля останутся нулями — сделаем об этом отдельный вопрос ниже. Ошибка возвращается в двух главных случаях: имя занято очередью с другими флагами — про это честный warn ниже — или соединение уже закрыто. Имя по конвенции пишут без пробелов: точки и дефисы разрешены, слэш не используют, чтобы не путать с путями vhost. Пустое имя — валидный случай: брокер сгенерирует уникальное имя с префиксом amq.gen-, типичное для эксклюзивных очередей ответов.

Очередь брокера похожа на буферизованный канал Go ровно до первой разницы. Канал живёт в памяти процесса: процесс умер — буфер исчез вместе с несчитанными значениями. Очередь живёт в отдельном процессе со своей памятью и опционально на диске: сервис падает, очередь продолжает копить сообщения, воркер перезапускается — и догребает недообработанное. Канал знает только свои значения; очередь ведёт счётчики готовых сообщений и потребителей, помнит, что кому выдано без подтверждения, и возвращает недоставленное при обрыве соединения. Канал безымянный и не переживает деплой; очередь — именованный долгожитель, чьи свойства фиксируются при создании. Обратная сторона: канал отдаёт значение горутине мгновенно и без обещаний, а очередь берёт на себя обязательства доставки — потому и требует подтверждений, что стоит отдельного протокольного обмена. Похоже на одно, а живёт совсем по-другому; это честный способ запомнить разницу, прежде чем сравнивать брокер с решениями на Redis.

Флаг durable=true делает очередь переживаемой: определение сохраняется на диск, и после рестарта брокера очередь снова готова принимать. Важно не путать с сохранностью сообщений: durable-очередь не делает сообщения долговечными — у сообщений свой флаг DeliveryMode, и разбор у девятого урока. Флаг autoDelete=true удаляет очередь, когда отключается последний потребитель: вариант для трансляций, где подписчики приходят и уходят, а копить нечего. Флаг exclusive=true ограничивает очередь одним соединением: другой клиент не объявит её и не подпишется, а при закрытии соединения брокер удалит очередь сам — так работают очереди ответов в RPC. Флаг noWait=true просит брокера не отвечать на объявление: экономится один сетевой рейс, но вместе с ним уходят счётчики и мгновенные ошибки — флаг ставят, когда уверены в параметрах. Флаги независимы, но сочетания осмысленны: durable вместе с exclusive — странная пара, ведь эксклюзивная очередь умрёт вместе с соединением, чего бы ни обещал durable. Выбирайте флаги под ответ на один вопрос: сколько должна жить очередь и кто имеет право её видеть.

QueueDeclare идемпотентен: если очередь с таким именем и эквивалентными параметрами уже существует, брокер вернёт её текущие счётчики и не создаст ничего заново. Из этого следует рабочая привычка — объявляйте очередь перед использованием: продюсер перед публикацией, потребитель перед подпиской. Кто встал первым, тот и создал очередь с финальными флагами; второй просто подключается. Так исчезает гонка старта, когда воркер запускается раньше продюсера и падает на публикации в несуществующую очередь. Но идемпотентность строгая по параметрам: флаги и аргументы должны совпасть один в один, любое расхождение — PRECONDITION_FAILED с закрытым каналом. Отсюда вторая привычка: параметры очереди выносят в общий пакет или константы, чтобы продюсер и потребитель не разъехались в правках. Отдельно про политики: часть свойств в продакшене задают не кодом, а policy на стороне брокера — те же TTL и лимиты; совпадающие свойства из кода и политики конфликтуют, поэтому прежде чем объявлять аргументы, посмотрите, что уже навешено политикой.

Счётчики из QueueDeclare — бесплатная диагностика, встроенная в самый первый вызов. MessageCount показывает сообщения в состоянии ready: лежат и ждут потребителя. Не вошедшие в это число unacknowledged — выданные, но неподтверждённые — в объявлении не видны; полную картину ready и unacked даёт management UI на вкладке Queues. ConsumerCount — число подписанных потребителей: ноль при растущей глубине означает, что воркеры не запустились или умерли, и очередь превращается в накопитель. Пара «глубина растёт, потребителей ноль» — самый частый сигнал инцидента, поэтому её же превращают в метрики: урок про наблюдаемость настраивает алерты на этих числах. В коде счётчики удобно логировать при старте: сервис печатает, сколько недоработки унаследовал, — и дежурный сразу видит, было ли затишье или копилось за ночь. Только не стройте на этих числах бизнес-логику: они снимаются в момент вызова и мгновенно устаревают; решение «брать ли задачу» по глубине на живой очереди всегда запаздывает.