Контакты

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (18)

Лучшие ответы пользователя

Все ответы (37)
  • Почему у rabbitmq такая низкая производительность?

    @yarkin
    В гугле по словам "rabbitmq" и "rpc" выдаётся ссылка на оф.документацию по Direct reply-to, Вы пробовали такой механизм? Создание/удаление очереди ради получения одного ответа это очень накладно. 50/400rpc это вообще не о чём, даже для RabbitMQ (конечно всё зависит от выделенных ресурсов, хранению на диске и т.д.).
    Ответ написан
  • Какая правильная архитектура с message bus для клиент-серверной IoT-системы?

    @yarkin
    Я не работал с IoT-устройствами, но мне кажется, что отдельная локальная шина звучит логично, так как позволит иметь наименьшие задержки и работать офлайн, а также, возможно, сэкономить батарею. Но зависит от задачи и ресурсов, может оказаться поначалу выгодней работать через серверв. RabbitMQ использовать на IoT-устройстве так себе идея, имхо, для простой отправки в маленьком масштабе он будет невыгоден по ресурсопотреблению.
    Ответ написан
  • Возможно ли увеличить максимальное значение клиентов RABBITMQ больше 65535?

    @yarkin
    С серверной стороны используется всего 1 порт, это клиентская часть выбирает случайный (по умолчанию), так что количество клиентов, которое может обслужить сервер RabbitMQ (да и любой другой сервис) не ограничено лимитом портов. (Например, в Linux каждое соединение характерирузется 5 параметрами {proto, src_ip, scr_port, dst_ip, dst_port}.)

    Ограничение дают вычислительные ресурсы, которыми распоряжается RabbitMQ. Так как очереди в RMQ не самые простые, то они потребляют достаточно памяти, я бы сказал, что каждая очередь (при условии что там немного сообщений) потребляет 30-50 КБ RAM. Можно попробовать включить режим Lazy Queue, чтобы RQM всегда писал/читал с диска и не кэшировал сообщения в памяти. Также RMQ любит процессор, но может хорошо распределить нагрузку между всеми ядрами.

    В кластерном режиме RabbitMQ может распределить очереди по всем серверам и обслуживать клиента на любом из них (но балансить клиентов также надо по всем узлам, в идеальности "привязать" клиента к одному серверу). Но проблемы начнутся, когда узлы RMQ начнут "падать" :-) Плюс метадата об очередях синхронизируется между всеми серверами, так что, если поток команд на создание/удаление очередей будет высок, то только на этом может съесться куча процессора и сети.
    Ответ написан
  • Есть ли Стратегия борьбы со сбросом состояния RabbitMQ?

    @yarkin
    1) Разработчики RabbitMQ ко всем потерям данных на стороне самого RabbitMQ относятся критично, так что, если в какой-то момент будете уверены, что теряет данные именно он, то смело создавайте баг (с подробностями как повторить).
    2) Если админы не умеют настраивать стейтфул приложения в контейнерной среде или куча ручных операций, то это больше административная задача, чтобы научиться и, например, использовать шаблоны/чарты/т.п. для предотвращения сюрпризов. Но также RabbitMQ в контейнере нужно настраивать, чтобы не получать деградации и дампов.
    3) Со стороны самого RabbitMQ есть зеркалирование очередей (queue mirroring) для дублирования данных, что позволит внезапно терять ноды (но восстановление может обойтись высоким потреблением процессора).
    4) Также рекомендую логировать и идентифицировать каждое отправленное и полученное сообщение, чтобы оценивать проблему. Для большей достоверности можно включить логирование ещё и на уровне RabbitMQ (если позволяют ресурсы). На прошлой работе у нас был свой плагин для RabbitMQ, который получал копию всех полученных и отправленных сообщений, выгребал из них нужную метаинформацию и отправлял в Graylog.
    5) Ну и конечно нужно делать отправку и приём с подтверждением, но это, я думаю, Вы и без меня уже делаете.
    Ответ написан
  • Как посмотреть и обработать сообщения с RabbitMQ?

    @yarkin
    Попробуйте вот такую штуку для отладки - Firehose Tracer. Какой ключ у биндинга сделали? Пробовали `#`?
    Ответ написан