Работает ли продюсер последовательно хэшируя потребителям через очередь сообщений? - PullRequest
Новая
       42

Работает ли продюсер последовательно хэшируя потребителям через очередь сообщений?

7 голосов
/ 02 сентября 2010

У меня есть производитель, которому я хочу равномерно распределять работу между потребителями путем последовательного хеширования.Например, в случае узлов-потребителей X и Y задачи A, B, C всегда должны идти к потребителю X, а D, E, F - к потребителю Y. Но это может немного измениться, если Z присоединится к пулу потребителей.

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

Одна из проблем, с которыми я сталкиваюсь, заключается в перечислении этих очередей, поскольку производителю необходимо знать все доступные очереди, прежде чем распределить работу.AMQP даже не поддерживает списки очередей, что делает меня неуверенным во всем моем подходе.RabbitMQ и Алиса ( на данный момент нереально ) добавляют эту функциональность, хотя: Существует ли API для перечисления очередей и обменов в RabbitMQ?

Это мудрое использованиеКролик?Должен ли я использовать очередь сообщений вообще?Есть ли лучший дизайн, чтобы очередь могла последовательно делить мою работу между потребителями, а не мне это нужно?

Ответы [ 2 ]

6 голосов
/ 03 сентября 2010

То, что вы описываете, выполнимо в RabbitMQ.

Ваша установка будет выглядеть примерно так:

  • производитель публикует сообщение для обмена темой;давайте назовем его constant_divider;
  • когда потребитель присоединяется к пулу, подключается к брокеру и создает исключительную очередь со своим именем, но периодически не привязывает его к чему-либо
  • производителюопрашивает брокера (возможно, используя rabbitmqctl list_consumers), чтобы проверить, изменились ли потребители;если они есть, он удаляет все существующие привязки и при необходимости перепривязывает очереди;
  • , когда производитель публикует, сообщениям присваивается ключ маршрутизации, соответствующий их типу задачи.

Итак, если у вас есть 6 типов задач: A, B, C, D, E, F и только два потребителя C1 и C2, ваши привязки будут выглядеть следующим образом: C1 привязан 3 раза к constant_divider с ключами маршрутизации A, B и C;C2 привязан 3 раза к c_d с помощью ключей маршрутизации D, E и F.

Когда C3 присоединяется к пулу, производитель видит это и соответственно перепривязывает очереди.

Когда производитель публикует, он отправляетсообщения с помощью routing_keys A, B, C, D, E и / или F, и сообщения будут перенаправлены в правильные очереди.

Возможны две возможные проблемы:

  1. Существует небольшая задержка между тем, когда потребитель присоединяется к пулу, и сообщениями направляются в него;также, если в очередях уже есть сообщения, для потребителя возможно получить сообщения, предназначенные для другого потребителя (например, присоединения C3, переподготовка производителя, но C2 все еще получает некоторые сообщения E и F, потому что они уже были в его очереди),
  2. Если потребитель по какой-либо причине умирает, сообщения в его очереди (и по пути в его очередь) будут потеряны;Эту проблему можно решить, переиздав и переписав сообщения соответственно.

Чтобы ответить на последний вопрос, вы, вероятно, захотите использовать организацию очередей, и RabbitMQ - отличный выбор, но ваши требования (точнее,немного «делим работу последовательно») не совсем подходят к AMQP.

0 голосов
/ 08 августа 2018

Вы можете использовать официальный согласующийся хэш плагин для rabbitmq, как ответили здесь

...