Насколько правильно, создавать большое кол-во очередей в RabbitmMQ?

Question

[topuserman]

Часто натыкаюсь на кейсы, rabbitmq используют в приложениях, или на сайтах, как систему доставки разных оповещений пользователю,
при этом для каждого пользователя, создается очередь, и в качестве роутинг ключа используется ID пользователя.

Является ли это хорошей практикой? Не страшно ли создавать для каждого пользователя очередь? и нужно ли что-то учитывать ? Например юдалять ли автоматически очередь, если пользователь не в сети или неактивный ?

Что делать, если пользователей чуть больше миллиона ? млн очередей - как-то будет серьезно влиять на производительность, если не учитывать объем данных в этих очередях ?

Comments

[Максим Федоров]

зачем так делать? почему одну не использовать под задачу?

[topuserman]

Максим Федоров, а как определять, какое сообщение для какого из тысячи клиентов ?

[Максим Федоров]

7876010,

Пример: При создании заказов — отправлять чек пользователю

• При заказе отправляем в кролик в очередь orders_cheque сообщение {user_id: 15, order_id: 345}
  
• Консюмер читает сообщения по очереди и в зависимости от нагрузки или каких-то алгоритмов как-то это делает, например берет id и достает всю инфу и отпарвляет все куда нужно... или делает что-то, и может быть на любом языке и делает это независимо от основного приложения... в этом суть
  
• И так по кругу, параллельно основному приложению, которое отправляет сообщения в очередь, консюмеры обрабатывают миллионы сообщений
  

Не совсем понимаю, откуда миллионы очередей взялись и зачем... Никогда не видел описанной вами архитектуры

[topuserman]

Максим Федоров, это получается, мы отправляем сообщение куда-то. А как их получать у клиентов? Для каждого клиента, может множество сообщений падать, которые надо обрабатывать.
И получается, у каждого клиента по консюмеру для этой задачи.

[Максим Федоров]

7876010, нет

выше написал вам, как это работает в общем случае

Answer 1

[Иван Шумов]

- можно использовать топики
- можно использовать заголовки
- можно использовать json параметры в теле сообщения

Comments

[topuserman]

А причем тут маршрутизация? не понял.
Вопрос не про то, как распределять сообщения в разные очереди.

[Иван Шумов]

7876010, это маркер, который можно получать в консьюмере. Поэтому не обязательно создавать очереди под каждого пользователя

[topuserman]

Иван Шумов, т.е. если для 10к пользователей, поступают сообщения, мне у каждого пользователя нужно из очереди получать все сообщения и брать только те, которые с пометкой для текущего пользователя?
Звучит как-то костыльно(

[Иван Шумов]

7876010, нет, это работает не так. Я привел пример документации. Предлагаю ознакомиться. Вообще стоит изучить на сайте RabbitMQ раздел get started. Там все разжевано

[topuserman]

Иван Шумов, на сайте я читал.
а как это работает? вы упоняли про эксченджи, а какую мысль хотели передать, не понял.

[Иван Шумов]

7876010, в rabbitmq все происходит через exchange. напрямую в очередь никто не пишет, ну, никто адекватный по крайней мере. Exchange это способ управлять трафиком. множество очередей как раз и появляются от того что кто-то думает что сходить и прочитать равносильно попробовать и понять.

Вряд ли у вас такой поток данных чтобы не писать однотипные сообщения по пользователям в разные очереди

Answer 2

[Сергей]

Тут всё зависит от задачи и терминологии. Например, "пользователь" может быть как какой-то объект системы, который не имеет прямого коннекта к RabbitMQ и отделен слоем другого ПО, так и быть непосредственно подключённым к нему. В первом случае на уровне RabbitMQ нужно будет иметь возможность различать типы промежуточного ПО (например, отправка сообщений по почте, по телеге и т.п.), возможно их группы (например, шардинг по регионам), а конкретный ID пользователя RabbitMQ знать совсем тут не нужно и он может быть частью тела сообщения. Во втором случае на уровне RabbitMQ уже нужно будет различать конкретных пользователей и ID уже должен быть частью метаданных, видных RabbitMQ.
Дальше, если перейти от термина "пользователь" к термину "клиент" (например), то в первом случае количество клиентов будет равно количеству инстансов промежуточного ПО (например, 1000), а во втором случае - количеству конечных пользователей (например, 1 млн). И тут можно сказать, что для каждого клиента (или группы равнозначных воркеров) нужно создавать очередь. В первом случае их будет тысяча, а во втором - миллион.

И да, очереди у RabbitMQ не самые лёгкие, по моему опыту (на версии 3.6-3.7) 10 тыс. очередей занимали около 800 МБ памяти.