#rabbitmq
#rabbitmq
Вопрос:
Я оцениваю использование RabbitMQ в качестве посредника очереди сообщений / фреймворка для замены встроенной очереди сообщений (используя C #, если это имеет значение).
У меня будет служба с N потоками, каждый поток будет потребителем для определенной очереди. Может быть несколько потоков, которые совместно используют одну и ту же очередь. Я полагаю, что я бы использовал свойство предварительной выборки, равное 1 для каждого потребителя, чтобы поток-потребитель получал по 1 сообщению за раз.
Давайте воспользуемся примером, в котором у меня есть 4 потока-потребителя, и все они просматривают очередь с именем «отчеты». Эти отчеты могут запускаться для разных «клиентов». Я хочу не позволять клиенту монополизировать очередь, поэтому, допустим, я не хочу, чтобы какой-либо один клиент использовал более 2 потребителей в любой момент времени (если есть другие ожидающие сообщения в очереди). Если нет других сообщений в очереди, ожидающих других клиентов, то я хотел бы разрешить всем потребителям иметь право.
Учитывая мое ограниченное понимание RabbitMQ на данный момент, я полагаю, что я мог бы либо использовать шаблон темы для указания клиента, либо я мог бы использовать пользовательский заголовок.
Я хотел бы знать, существует ли шаблон проектирования для поддержки определения ограничения для уникального заголовка / значения клиента.
Я не прошу никого писать код за меня, я просто хочу знать, может ли кто-нибудь сказать мне «нет, это не сработает» заранее, прежде чем я потрачу кучу времени на наращивание.
Если мой вопрос не имеет смысла, пожалуйста, дайте мне знать, и я обновлю его дополнительной информацией. Заранее спасибо.
Комментарии:
1. Возможно, вам захочется заглянуть в приоритетные очереди , установить высокий приоритет, а затем уменьшить его, если количество сообщений, полученных для данного клиента за данный период времени, превышает пороговое значение (это также будет означать, что вам потребуется промежуточный шаг, если издатели являются клиентами)
2. Спасибо @Olivier, я изучу это подробнее. Другим вариантом, который я оценивал, была концепция подтверждения вручную и чтобы потребитель проверял, сколько неподтвержденных сообщений ожидают очереди, сгруппированных по клиенту, а затем «просматривал», есть ли какие-либо сообщения в очереди (еще не распределенные) для другого клиента. Если да, то я подумал, что мог бы заставить потребителя выдать отрицательный Ack обратно и указать ему запрос. Я не уверен, что все это пока возможно.
3. Если вы «отключите», сообщение будет отправлено в начало очереди, так что это не сработает. Что вы могли бы сделать, так это заставить потребителя повторно отправить сообщение через exchange, чтобы оно оказалось в конце очереди. Но, насколько я знаю, нет функции, которая соответствовала бы концепции подглядывания, вы либо используете (и, возможно, отключаете), либо нет. Если вы хотите пойти по этому пути, вы могли бы попросить потребителя (ов) проверить где-нибудь еще (DB, Redis, …) количество обработанных сообщений для данного потребителя и решить опубликовать сообщение повторно без обработки.
4. Спасибо @Olivier. В настоящее время мы делаем это через нашу собственную очередь, поддерживаемую базой данных, где наши потребители, по сути, «извлекают» сообщение, но это требует большого количества запросов к базе данных, и нам не нравится масштабируемость. Я также просматриваю Amazon MQ с использованием ActiveMQ (мы являемся магазином .net), поэтому я попытаюсь оценить, есть ли другой механизм, который мог бы быть возможен с ActiveMQ. Я ценю ваш вклад.
5. Привет, Стив, спасибо за дополнительный контекст. Из любопытства, о скольких клиентах мы говорим?