Ответы пользователя по тегу RabbitMQ
  • Как задать консьюмеру IBMMQ количество вычитываемых сообщений?

    как настроить консьюмер IBMMQ так, чтобы он забирал из очереди не все сообщения - без ограничений - которые ему хочет выдать сервер (менеджер), а как-то дозированно: по 1, 2, N и только после обработки уже вычитанных вычитывал следующие?

    Зачем?
    Используй СУБД, считывая записи с LIMIT, OFFSET
    Ответ написан
  • Почему не запускается RabbitMq в докере?

    Проще всего удалить директории с данными в текущей директории:
    1. ./postgres-data
    2. ./rabbitmq-data

    и поменять проверку на эту:
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "status"]
      interval: 30s
      timeout: 10s
      retries: 3
    Ответ написан
    Комментировать
  • Как релизаовать двустороннюю связь серверов в веб разработке?

    Для "общения" серверов между собой можно использовать WebSocket, gRPC, HTTP и много чего ещё. Если они в одной подсети, то это значительно упрощает их взаимодействие.
    Сервер в роли диспетчера может отправлять задачи и контролировать их выполнение: отправить задачу с её идентификатором, а при получении ответа записать в СУБД, что задача Х выполнена. Там же и проверить, что если все задачи подсерверов выполнены, то перейти к следующему этапу.
    Ответ написан
    Комментировать
  • Как в RabbitMQ обработать все сообщения а затем удалить очередь и закрыть соединение?

    Странная затея насчёт удаления очереди.
    Ну если так надо, то отправляй сообщение о том, что окончились сообщения. Тогда обработчик очереди получит его и будет знать, что очередь можно удалять.
    Ответ написан
    Комментировать
  • Какой тип обмена использовать в этом случае?

    Если нужна доставка одного и того же сообщения нескольким сервисам, то fanout подходит.
    Если нужно разослать сообщение по разным подкатегориям по маске (скажем, регионам), то можно использовать обмен типа topic.
    https://dev.to/larapulse/dealing-with-rabbitmq-exc...
    Ответ написан
    Комментировать
  • Как спроектировать python приложению, реализующее консьюмера RabbitMQ и требующего HealthCheck?

    У приложения потребителя очереди должен иметься менеджер соединения с RabbitMQ. Как только соединение было установлено, запускается поток с веб-сервером и health-check. У потребителя очереди - основой поток, у веб-сервера - дочерний. Каждый работает независимо друг от друга. Для менеджера соединения с RabbitMQ может использоваться функция обратного вызова в библиотеке.
    Таким образом, при вызове /health (или /health/live) всегда возвращается статус 200.
    При внезапном разрыве соединения с RabbitMQ менеджер соединения приложения штатным образом пытается восстановить соединение (скажем, до N раз каждую секунду) и если облом, то выходим из приложения с ненулевым статусом (допустим, 1). Если приложение падает, то вместе с ним и health-check, что вызовет триггер по перезапуску приложения у процесса, который ведет мониторинг приложения.
    Мониторинг самого RabbitMQ обычно ведется отдельными от приложения средствами. RabbitMQ может запускаться как on premises, так и в SaaS (допустим, CloudAMQP).
    Ответ написан
    Комментировать
  • Как правильно обработать товары в очереди?

    1) Насколько правильно обрабатывать в одной очереди и загрузку файла и парсинг самого файла?
    Если произойдёт какая-то ошибка при чтении файла
    Пока я не вижу смысла в дополнительной очереди. При скачивании нужно определять код статуса и если возвращает 20x, то можно приступать к чтению. Если 40x, то это баг клиента. Если 50x или сбой связи, то можно сохранить в таблице с временем последней попытки, чтобы можно было выбирать когда нужно провести следующую попытку.
    Если файл скачан без ошибок и он цел, то проблем с чтением файла быть не должно, при условии соблюдения формата файла. А если скачан частично при коде 20x, то повторная обработка ничего не даст.
    Скачанный файл можно удалять, если импорт окончен. А при сбое можно заново не скачивать - экономия времени.
    Смену статуса импорта сделать сразу по окончанию обработки.

    2) Запись сообщений в лог происходит в отдельной очереди, а для смены статуса импорта желательно отправлять сообщения в отдельную очередь или можно прямо здесь выполнять код для смены статуса?
    не понял почему нужна очередь для лога.

    только изображения отправляются для обработки в одельной очереди. Я думаю, что это сильно напрягает саму очередь
    сами изображения отправляются или что-то другое? Если первое, то это нелогично и это действительно нагружает очередь. Зачем все товары слать в очередь? Разве в очереди импорта нельзя считывать всё с файла и записывать сразу в СУБД? Это ведь никого задерживать не будет.

    Получается, что все товары висят в одной очереди и ждут когда их проверят.
    Нет, очередь нужна для обработки без ожидания. А для хранения используется СУБД с пометкой последней проверки и, возможно, временем, когда товар надо снова обновить. Какой-то периодический процесс может опрашивать таблицу: у кого протухли товары, отзовись!
    Ответ написан
  • Что может писаться в персистентное хранилище в rabbitmq?

    1. Проверить, работает ли обработчик очереди, не падает ли из-за ошибок
    2. Проверить наличие ack обработчиком. https://www.rabbitmq.com/confirms.html
    3. Проверить темп публикации сообщений и его потребления. Если недостаточный у обработчика, то оптимизировать время обработки и добавить дополнительный, при необходимости.
    Ответ написан
    Комментировать
  • Ошибки запуска RabbitMQ. Как решить?

    Crash dump is being written to: /var/log/rabbitmq/erl_crash.dump..

    Вот там ответ и кроется.
    Ответ написан
    Комментировать
  • Почему низкая скорость публикации сообщений в очередь RabbitMQ?

    Вообще, AMQP - непростой протокол и в нам есть много взаимодействий по сети. У разных реализаций протокола могут быть разные особенности, даже в пределах того же языка программирования.
    Если отправка по интернету, то вообще все может быть менее предсказуемо и соединения могут отваливаться спонтанно, что может приводить к "заморозке" или частым переподключениям.
    Не предоставлено никакой информации об:
    используемых версиях библиотек и RabbitMQ, рантайма, конфигураций сети, ... как и самого кода.
    Ответ написан
    Комментировать
  • Как в Django установить соединение с RabbitMQ?

    Уверен, что есть множество реализаций AMQP и для Python. У каждой из них должная быть своя документация.
    При инициализации проекта можно создать соединение или даже лучше пул соединений, используя которое/ый в некотором издателе, отправлять в нужную очередь.
    Ответ написан
    Комментировать
  • Почему сообщения из очереди обрабатываются, не ожидая окончания их выполнения, несмотря на await?

    2ord
    @2ord Автор вопроса
    После создания канала необходимо указать
    await this.channel.prefetch(1); // или другое кол-во, которое хотим обрабатывать одновременно.
    Ответ написан
    Комментировать
  • Можно ли с помощью rabbitMQ можно ли создать очередь в которой для каждого пользователя последовательно будет выполнятся запрос на другой сайт?

    Если ответ клиенту на его запрос выдается не сразу, а с задержкой в связи с ограничениями из-за API третьей стороны, то логично ввести систему заявок. При запросе регистрируют заявку клиента, заносят данные в СУБД, кладут в очередь и сразу выдается ответ с номером заявки и ожидаемым временем готовности. Когда обработчик очереди берет задачу с учетом задержки 5 секунд, получает ответ от API и заносит ответ в готовой для последующего чтения форме в СУБД для соответствующего номера заявки. Независимо от обработчика очереди, клиенты обращаются за получением готовых результатов. И если таковые готовы (проверка по колонке в таблице), выдается ответ. Если еще не готов, выдается следующее ожидаемое окно времени. И т.д., до лимита проверок.

    Если же перед ответом дожидаться пока пройдет 5 секунд, то такая система быстро захлебнется при наплыве запросов и будут исчерпаны ресурсы. Поэтому RPC не рассматриваю как подходящий вариант работы.
    Ответ написан
    Комментировать
  • Как с фронта слушать ответ от rabbitmq?

    какую библиотеку можно использовать для отображения поступившего запроса в реальном времени?
    При помощи SSE можно передать клиенту какие-то данные без необходимости обновления страницы.
    Как только статус обновляется, отправлять по SSE сообщение со статусом или любой другой информацией.
    Ответ написан
    1 комментарий
  • При запуске RabbitMQ выводится ошибка. Как решить?

    Написано же:
    17:10:49.061 [error] ERROR: distribution port 25672 in use by another node: rabbit@DESKTOP-PS7PKS9
    ERROR: distribution port 25672 in use by another node: rabbit@DESKTOP-PS7PKS9
    По какой-то причине порт уже занят.
    Ответ написан
    Комментировать
  • MicroMQ и RabbitMQ очередь запросов внутри сервиса?

    Хотел бы понять что означает
    намертво вешает систему.
    в контексте микросервисов? И почему это является проблемой?

    Тот получает кучу одинаковых заданий
    А почему нужно обрабатывать одинаковые URL повторно?
    Если, конечно, сильно надо, то можно проверять в K/V хранилище на наличие ключа с таким URL , у которого ограничено время жизни. Тогда при повторном событии просто игнорировать его.

    Ну а, вообще, микросервис "Браузер" может работать только в качестве обработчика очереди, получая сообщения, отправленные REST API. Сам же просто складывать в своем темпе результаты сканирования URL в СУБД, а REST API будет проверять наличие в той же СУБД и сообщать результаты клиенту, если готово.
    Ответ написан
  • Как правильно организовать очереди?

    А в чём проблема отправлять из сервис_1 в брокер и идентификатор пользователя и идентификатор сервиса (экземпляра), к которому он подключен? Тогда каждый экземпляр сервис_2 будет знать кому предназначена команда. Не вижу смысла плодить очереди на каждого пользователя (и тем более заниматься их управлением) и даже для каждого экземпляра сервис_1.
    Так что я за более простой вариант:
    Или это все одна очередь и каждое сообщение должно быть вычитано каждым инстансом сервиса_1 а затем отфильтровано?
    Ответ написан
  • Стоит ли переносить с крона в очереди?

    Можно сделать такой вариант запуска задач:
    Планировщик задач запускает программу, проверяющую какие-то условия и когда получено решение о выполнении задачи, отправляет в очередь указание с необходимыми для выполнения аргументами и затем программа сразу завершается. При такой схеме не будет висеть процесс программы долгое время, а консюмеры будут обрабатывать задачи асинхронно и поочередно.
    Но для такого малого количества задач затея сомнительна.
    Ответ написан
    Комментировать
  • Как обрабатывать задачи группами?

    Если я отправлю в очередь 'send_push' сообщение '{post_id: 123}': , его получит консьюмер, выберет из БД 1тыс пользователей
    А что мешает консьюмеру брать из БД по 1000 в цикле?
    Ответ написан
  • Выбор коммуникации между сервисами?

    По окончанию регистрации необходимо отправить уведомление, поэтому логично сделать это через брокер сообщений (RabbitMQ и др.).
    Служба Уведомления представляет из себя потребителя очереди и рассылает письма асинхронно относительно регистрации.
    Сам транспорт менее важен чем то когда событие будет обработано.
    Транспортом может быть и HTTP, и WebSocket.
    Ответ написан
    Комментировать