Какова причина лучшей практики NServiceBus «один распространитель на тип сообщения»?

Question

Я видел несколько раз упомянутое в качестве лучшей практики, что для каждого типа сообщения должен быть настроен один процесс распространения, но никогда не было объяснения, почему это так. Поскольку увеличение числа дистрибьюторов увеличивает сложность развертывания, я хотел бы знать причины этого. Я предполагаю, что если все доступные подписчики для данного типа сообщений заняты, распространитель может застрять в ожидании освобождения одного, а сообщения других типов, которые могут иметь свободных подписчиков, накапливаются в рабочей очереди распространителя. Это точно? Любые другие причины?

Answer 1

Это правда, что Дистрибьютор не будет раздавать больше работы, пока работник не закончил.Поэтому, если работники связаны с данным типом сообщения, остальные будут сидеть там, пока они не закончат.У NSB нет понятия приоритета, все сообщения созданы равными.Рабочие не подписываются на определенные типы сообщений, они просто получают работу от распространителя.

Если некоторые типы сообщений имеют «приоритет» над другими, то у них должен быть свой собственный распространитель.Если «приоритет» все тот же, то добавление большего количества работников повысит производительность до определенной точки.Это будет зависеть от того, над чем вы работаете.Если это база данных, ваша конечная точка может быть связана с большим количеством данных, чем с процессором.В этом случае добавление большего количества рабочих не поможет, так как они создают растущую конкуренцию на одном и том же ресурсе.В этом случае вам может понадобиться разбить ресурс на части как.

Answer 2

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

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