Pika Python связывает программу с RabbitMQ, но сообщение ещё не означает готовую задачу. На примере фото объясняю очередь, подтверждения и проверку результата.
М
Марина
Контент-маркетолог LibraChat
6 мин чтения
Коротко: Pika передаёт сообщения между Python-программой и RabbitMQ. Она не обрабатывает фотографии сама и не устанавливает сервер очереди. Если сообщение отправлено, результат ещё предстоит сделать отдельному обработчику.
«В интерфейсе написано “отправлено”, почему фото не готово?» — спросил коллега перед выпуском каталога. У нас было 24 снимка: один процесс ставил задания на подготовку миниатюр, другой должен был их выполнять. Я сначала смотрела на кнопку и журнал отправки. Потом поняла, что они отвечают только за начало пути. Запрос Pika Python часто приводит к примеру из нескольких строк, но за этими строками стоит очередь, потребитель и проверка результата.
Pika Python сама запускает RabbitMQ?
Нет. Pika — библиотека клиента для протокола AMQP 0-9-1. Она позволяет Python-программе подключиться к брокеру сообщений, объявить очередь, отправить или принять сообщение. В официальном учебном примере RabbitMQ сервер уже должен работать. Команда установки библиотеки выглядит как python -m pip install pika; она добавляет пакет в среду Python, но не запускает брокер.
Я проверила это различие по нашей схеме: кнопка в редакторском интерфейсе не имеет собственного хранилища задач. Её серверный обработчик кладёт сообщение в очередь. Отдельная программа ждёт его и делает миниатюру. Если второй программы нет, сообщение может ждать, а интерфейс будет знать только об отправке. Назвать это «фото готово» нельзя.
Две программы: отправитель и потребитель, который знает, что делать с сообщением.
Если у тебя один скрипт, который последовательно обрабатывает 24 файла, очередь может оказаться лишней. Она нужна, когда постановку работы и выполнение полезно разнести: например, интерфейс быстро принимает задание, а обработчик трудится позже. Я бы сначала нарисовала два процесса и стрелку между ними. Если второго процесса на схеме нет, библиотека пока не решает задачу.
«basic_publish прошёл» означает, что миниатюра готова?
Нет. Отправитель публикует сообщение. Потребитель берёт его и выполняет работу. Это разные события, иногда разделённые минутами. Для редактора каталог не готов, пока нет файла нужного размера и статуса обработки.
Я раскладываю путь по действиям:
Событие · Кто за него отвечает · Что оно доказывает
Запрос в интерфейсе принят — Веб-приложение — Пользователь отправил задачу
Сообщение опубликовано — Отправитель через Pika — Задание ушло брокеру при заданных условиях
Сообщение выдано потребителю — RabbitMQ и обработчик — Работа началась или ждёт начала
Обработчик подтвердил сообщение — Потребитель — Он сообщил брокеру о завершении обработки сообщения
Миниатюра проверена — Приложение или редактор — Нужный результат действительно появился
Последняя строка часто теряется. Подтверждение сообщения само по себе не показывает редактору изображение и не проверяет его качество. Обработчик мог создать файл неверного размера, если в задаче был неверный параметр. Я проверяю итог отдельно: имя, размеры, открывается ли файл. Мне нужна готовая карточка, а не только успешный обмен сообщениями.
Очередь не равна файлу.
Я попробовала нарисовать статус для коллег без слова «готово» на раннем этапе: «принято», «ожидает», «обрабатывается», «файл проверен» и «ошибка». Так сразу видно, где зависла фотография. Я проверила за 5 минут несколько карточек по такой схеме и поняла, что отметка отправителя в интерфейсе должна называться «поставлено в очередь». Это два события. Если миниатюра появится позже, статус должен измениться тогда, а не при нажатии кнопки.
Вот минимальный фрагмент отправителя по форме официальных примеров Pika:
Тут нет обработки фотографии. В сообщении только условный идентификатор, который должен понять потребитель. Пример предполагает работающий RabbitMQ на локальном компьютере; без него подключение не состоится. Я не вставляю в текст настоящие адреса сервера, учётные данные или названия клиентских файлов.
Pika Python гарантирует, что задача никогда не потеряется?
Нет такой короткой гарантии. В учебнике RabbitMQ различают долговечность очереди, сохранение сообщения и подтверждение его обработки потребителем. Устойчивое поведение требует продумать все три места. Даже отметка сообщения как persistent не равна обещанию «никогда не потеряется»: документация отдельно описывает окно между приёмом сообщения и его сохранением на диске. Для более сильной уверенности издателю нужны подтверждения публикации.
Есть и другая сторона. Если обработчик получил сообщение и упал до подтверждения, задача может быть выдана снова. Значит, обработка должна переносить повтор без порчи результата. Для фотографий это вопрос имени выходного файла и способа записи: повторное задание не должно случайно испортить уже готовую миниатюру. Я проверила на схеме, где у нас появляется слово «готово»: только после создания файла, а подтверждение очереди следует за успешной работой.
Мой короткий список для обсуждения с разработчиком:
очередь объявляется с нужными параметрами и одинаково на обеих сторонах;
сообщения, которые должны пережить перезапуск брокера, публикуются с соответствующим режимом;
потребитель подтверждает работу после успешного действия, а ошибка остаётся видимой;
отправитель различает «отправил» и «брокер подтвердил», если потеря задачи критична.
Для срочной рассылки карточек я бы добавила ещё проверку количества: было 24 задания, значит перед выпуском нужно увидеть 24 пригодных миниатюры или список конкретных ошибок. Одна зелёная строка в журнале отправителя такого ответа не даёт.
«Очередь решит тормоза» без наблюдения за ней?
Очередь отделяет быстрый приём задачи от долгой обработки, но сама по себе не делает обработчик быстрее. Если входящих фотографий больше, чем он успевает обрабатывать, список ожидающих растёт. В учебном материале RabbitMQ для распределения задач между обработчиками используется ограничение числа неподтверждённых сообщений на одного работника. Это помогает распределять нагрузку, но не заменяет наблюдение за длиной очереди.
Я бы начала с трёх вопросов: сколько заданий ожидает, сколько обработано за выбранный период, сколько закончилось ошибкой? Только после этого решала бы, нужен ли второй обработчик. Иначе к медленному процессу добавится второй медленный процесс, а причина задержки останется неизвестной.
Если в твоём проекте есть фрагмент с Pika, попробуй открыть LibraChat и попросить объяснить путь сообщения: где публикация, где обработчик и где подтверждение. Для работы с кодом пригодится разбор задач программиста; доступные функции и условия смотри в тарифах. Я бы не принимала фразу «очередь работает» без последней строки таблицы: где доказательство готового файла?
