Как настроить ребус на одного производителя и много потребителей

Я просматриваю образцы и читаю документы, но я все еще не уверен, как настроить ребус для моего сценария (или что использование шины подходит).

У меня есть один производитель задач, скажем, ImportOrder и CalculateOrderPrice.

Я хочу сбрасывать сообщения от производителя и ставить в очередь много этих сообщений. Мне нужны два клиента, которые слушают ImportOrder, и 10 клиентов, которые слушают CalculatePriceOfOrder. Я не хочу, чтобы один и тот же заказ шел к нескольким конечным точкам одновременно, я пытаюсь распределить рабочую нагрузку.

Конфигурация производителя на данный момент:

 <rebus inputQueue="publisher.input" errorQueue="publisher.error" workers="1" maxRetries="5">


var adapter = new BuiltinContainerAdapter();
            Configure.With(adapter)
                   .Logging(l => l.Log4Net())
                        .Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
                        .Subscriptions(s => s.StoreInXmlFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "rebus_subscriptions.xml")))
                        .MessageOwnership(d => d.FromRebusConfigurationSection())
                        .CreateBus()
                        .Start();

Consumer config so far:

<rebus inputQueue="calcserver1.input" errorQueue="calcserver1.error" workers="1" maxRetries="5">
<endpoints>
  <add messages="Messages.RecalculateContractMessage,  Messages" endpoint="[email protected]"/>
</endpoints>


Configure.With(adapter)
               .Logging(l => l.Log4Net())
                .Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
                .MessageOwnership(d => d.FromRebusConfigurationSection())
                .CreateBus()
                .Start();

        adapter.Bus.Subscribe<RecalculateContractMessage>();

I cant seem to configure this setup, it does not really matter if I use msmq or sqlserver.

  • Подойдет ли здесь rebus (или любое другое решение типа сервисной шины)?
  • Должен ли я использовать публикацию/подписку или обычный шаблон отправки? И повлияет ли этот выбор на обработку сообщений только одной конечной точкой или несколькими?
  • Может ли кто-нибудь указать мне на хороший пример или объяснить, как настроить этот сценарий?

servicebus messaging rebus
person Jon    schedule 07.02.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я отвечу на ваши вопросы один за другим:

  • Подойдет ли здесь ребус (или любое решение типа сервисной шины)?

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

  • Должен ли я использовать публикацию/подписку или обычный шаблон отправки? И повлияет ли этот выбор на обработку сообщений только одной конечной точкой или несколькими?

В этом случае мне кажется, что вам нужен тип распространения конкурирующих потребителей. ваших задач.

Это НЕ публикация/подписка — публикация/подписка подразумевает 0..* получателей для каждого экземпляра сообщения, но вам нужен ровно один получатель для каждой задачи. Поэтому в этом случае вы бы bus.Send выполнили задачи.

  • Может ли кто-нибудь указать мне на хороший пример или объяснить, как настроить этот сценарий?

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

Вам должно быть довольно легко начать работу, просматривая сообщения и используя, например. SQL Server в качестве вашего транспорта.

person mookid8000    schedule 09.02.2014
comment
Большое спасибо, я прочитал серию, и они великолепны :) Я начну с решения для масштабирования сервера sql, оно звучит как хорошее решение. - person Jon; 09.02.2014
comment
Дополнительный вопрос: скажем, у нас есть два разных сообщения и 0..* worker для каждого сообщения. Будут ли две разные очереди решением? Попытка обрабатывать разные сообщения на одной и той же шине создает множество проблем. - person Jon; 10.03.2014
comment
Я думаю, что понял это прямо сейчас, используя bus.Advanced.Routing.Send для определенных очередей и настройку каждого рабочего типа для потребления из этой очереди. Если это предлагаемый путь, то, возможно, я мог бы внести свой вклад с образцом, если хотите :) - person Jon; 10.03.2014
comment
Что вы имеете в виду, говоря, что попытка обработки разных сообщений на одной шине, похоже, создает много проблем? - person mookid8000; 10.03.2014
comment
Я думаю, что у меня была немного странная установка, два разных сообщения в одной сборке, скажем, OrderProductMesage и RegisterMemberMessage. Я сбрасывал сообщения обоих типов в одну и ту же очередь. Затем я создал двух отдельных рабочих процессов, которые потребляли сообщения из этой очереди. Это привело к ошибкам маршрутизации. Но когда я начал использовать очередь для каждого сообщения и настроить int немного более явно, это работает очень хорошо :) - person Jon; 11.03.2014
comment
Ах, верно! Когда воркеры обрабатывают сообщения из одной и той же очереди, воркеры должны быть экземплярами одного и того же рабочего процесса — но, похоже, вы все правильно поняли;) - person mookid8000; 11.03.2014