Как правильно использовать диспетчер тайм-аута с дистрибьютором в NServiceBus 3+?

В версии pre-3 рекомендовалось запускать диспетчер тайм-аутов как отдельный процесс в вашем кластере рядом с распространителем. (Как описано здесь: http://support.nservicebus.com/customer/portal/articles/965131-deploying-nservicebus-in-a-windows-failover-cluster).

Как правильно использовать диспетчер тайм-аута в качестве сателлитной сборки при масштабировании с дистрибьютором?

Должен ли каждый сотрудник службы A работать с включенным диспетчером тайм-аута или должен быть настроен только процесс распространителя для службы A для запуска диспетчера тайм-аута для службы A?

Если каждый работник запускает его, используют ли они один и тот же экземпляр Raven для хранения тайм-аутов? (И если так, как вы можете быть уверены, что два или более рабочих не соберут один и тот же истекший тайм-аут в одно и то же время?)

2 ответа

Решение

Позвольте мне четко ответить на этот вопрос.

После долгих поисков и с помощью Андреаса Элунда из команды NSB ( http://tech.groups.yahoo.com/group/nservicebus/message/17758) правильный ответ на этот вопрос:

  • Как упоминал Уди Дахан, ТОЛЬКО по проекту ТОЛЬКО узел дистрибьютора / мастер должен запускать диспетчер тайм-аута в сценарии горизонтального масштабирования.
  • К сожалению, в ранних версиях NServiceBus 3 это не реализовано, как задумано.

У вас есть следующие 3 вопроса:

1) Работа с профилем распространителя НЕ запускает менеджер тайм-аута.

Временное решение:

Запустите диспетчер тайм-аутов на распространителе самостоятельно, включив этот код на распространителе:

class DistributorProfileHandler : IHandleProfile<Distributor> 
{
   public void ProfileActivated()
   {
       Configure.Instance.RunTimeoutManager();
   }
}

Если вы запускаете мастер-профиль, это не проблема, так как диспетчер тайм-аута автоматически запускается на главном узле.

2) Работники, работающие с профилем работника, каждый запускают локального менеджера тайм-аута.

Это не так, как задумано, и портит опрос против хранилища тайм-аута и диспетчеризацию таймаутов. Все работники опрашивают магазин тайм-аутов: "Дайте мне время ожидания МАСТЕРНОД". Обратите внимание, что они запрашивают тайм-ауты MASTERNODE, а не W1, W2 и т. Д. Таким образом, некоторые работники могут в конечном итоге получить одинаковые тайм-ауты из хранилища тайм-аутов одновременно, что приведет к конфликтам с Raven при удалении тайм-аутов из него.

Диспетчеризация всегда происходит через локальные очереди.timouts /.timeoutsdispatcher, тогда как она ДОЛЖНА осуществляться через очереди диспетчера тайм-аутов на MasterNode/Distributor.

Обходной путь, вам нужно сделать оба:

а) Отключить менеджер времени ожидания на рабочих. Включите этот код на ваших работников

class WorkerProfileHandler:IHandleProfile<Worker>
{
    public void ProfileActivated()
    {
        Configure.Instance.DisableTimeoutManager();
    }
}

b) Направьте NServiceBus на рабочих, чтобы использовать очередь.timeouts на MasterNode/Distributor.

Если вы этого не сделаете, любой вызов RequestTimeout или Defer на работнике прекратится, за исключением того, что вы забыли настроить диспетчер тайм-аута. Включите это в ваш рабочий конфиг:

<UnicastBusConfig TimeoutManagerAddress="{endpointname}.Timeouts@{masternode}" /> 

3) Ошибочные "Готовые" сообщения обратно дистрибьютору.

Поскольку диспетчер времени ожидания отправляет сообщения непосредственно во входные очереди рабочих, не удаляя запись из доступных рабочих в очереди хранения распределителя, рабочие отправляют ошибочные сообщения "Готов" обратно дистрибьютору после обработки тайм-аута. Это происходит, даже если вы исправили 1 и 2, и не имеет значения, был ли тайм-аут получен из локального менеджера тайм-аута на рабочем месте или на одном, работающем на распространителе / ​​MasterNode. Следствием этого является создание дополнительной записи в очереди хранения на распространителе для каждого тайм-аута, обрабатываемого работником.

Обходной путь: используйте NServiceBus 3.3.15 или новее.

В версии 3+ мы создали концепцию главного узла, в котором размещены все спутники, такие как распределитель, диспетчер времени ожидания, шлюз и т. Д.

Мастер-узел очень прост в использовании - вы просто передаете флаг /master процессу NServiceBus.Host.exe, и он запускает все для вас. Итак, с точки зрения развертывания, где вы использовали для развертывания распределителя, теперь вы развертываете главный узел.

Другие вопросы по тегам