Ответ

sergei v.2 15.09 14:01

Возможно как-то стоит разделить методы, выделив достаточные для простого режима (только работа с очередями через default exchange) и методы расширенного режима

Я думаю, что методов там и так минимум, а реализовать это можно через дефолтные значения параметров, чтобы их лишний раз не писать в коде. А в расширенном режиме задавать этим параметрам недефолтные значения (если надо).

declare_queue не должен принимать exchange: объявление очереди != привязка к бирже.

Не факт. Я не очень представляю ситуацию, когда можно создать очередь без биржи. Мне кажется если создать очередь без биржи, то ребит сам создаст биржу и привяжет туда эту очередь (Может конечно я чего-то не догоняю)

Нужен отдельный метод bind_queue(exchange, queue, routing_key, args) и unbind_queue.

Это связано в предыдущим методом declare_queue - в 99,99% придется писать вызов двух методов вместо одного, bind я бы наверное все же спрятал в declare_queue. Либо писать потом парсерный класс обертку и там это два метода оборачивать в один. Вопрос зачем??

publish должен иметь routing_key. Поле queue допустимо только как сахар для публикации в default exchange ("") с routing_key = queue.

Если у нас явно нету bind_queue, где связывается routing_key и queue, то у нас по факту нет routing_key и публикуем мы либо в конкретную очередь или в биржу (== сразу в разные очереди, привязанные к этой бирже)

consume.no_ack описан наоборот. Должно быть: no_ack=true = авто-подтверждение; no_ack=false = ждать явный ack/nack.

no ack == нет подтверждения == авто-подтверждение (согласен - косяк, надо исправить)

delete_exchange.if_unused и описания «удалится очередь» — терминологическая ошибка. Речь про использование биржи (имеются ли привязки).

Да опечатка (копипаст) - конечно же биржа, а не очередь

declare_exchange.passive / declare_queue.passive: описание «ничего не делает если существует» верно, но добавьте явное «и бросает ошибку, если не существует»

вроде так и написано (только опять копипаст для биржи написано про очередь - надо исправить)
если true, не объявляет очередь, а проверяет ее существование и выдает исключение если ее не существует,
если false и очередь существует, ничего не делает

reject обычно имеет флаг requeue (или отдельный nack(requeue=true|false)), его нет.

Нет QoS/prefetch (важно для fair-dispatch).

Нет tx/confirm режима (publisher confirms) — критично для гарантированной доставки.

пока ноу коммент :)

Параметр properties стоит структурировать: headers, content_type, delivery_mode, expiration, priority, correlation_id, reply_to, message_id, timestamp, type, app_id.

Там так и написано, что это hash

В publish опции create_queue/create_exchange удобны, но опасны (гонки, права). Лучше вынести в явные шаги или сделать их отключаемым сахаром.

Они и добавлены для удобства и значения по умолчанию делать очередь и/или биржу если их нет, чтобы каждый раз не писать. А если надо, то явно это выключать.

read_timeout/write_timeout: у вас оба «для записи». Исправить описания и явно указать единицы (ms).

Опечатка (копипаст). Секунды или милисекунды надо наверное всюду свести к милисекундам.

heartbeat(0) по умолчанию нежелателен. Рекомендуется 30–60 сек.

ок - 30 000 ms (в милисекундах??)

TLS: обычно нужны флаги verify_peer, verify_hostname, SNI.
login_method: дефолт — PLAIN у RabbitMQ; укажите, как выбирается. login_response редко нужно — можно скрыть.
channel_rpc_timeout в секундах? Уточнить единицы.
keepalive системный (TCP) ? AMQP heartbeat — стоит пояснить.

ну тут сложно мне комментировать

---