NServiceBus: разве MSMQ транзакции не плохие? - PullRequest
5 голосов
/ 18 августа 2010

Я узнаю о NServiceBus и MSMQ. Мне сказали, что транзакционные очереди в MSMQ ПЛОХО, и их использование очень плохо для производительности. Кто-нибудь знает почему? Я предполагаю, что это происходит из-за того, что он использует DTC, и все знают, что DTC на самом деле не является масштабируемым решением. Мне кажется, что есть несколько причин, по которым MSMQ с NServiceBus не так уж и плох, но я не знаю, понимаю ли я, как он работает полностью. Глядя логически, я могу вспомнить 3 места, где NServiceBus может использовать транзакции для получения гарантированной доставки:

  1. При отправке сообщения по сети вы можете захотеть использовать транзакцию, чтобы убедиться, что сообщение попало в удаленную очередь, прежде чем вы его отбросите.
  2. При чтении сообщения из локальной очереди может потребоваться убедиться, что оно успешно обработано, прежде чем его отбрасывать.
  3. При публикации сообщения нескольким подписчикам может потребоваться убедиться, что оно достигнет ВСЕХ из них, прежде чем его отменить. (Я действительно надеюсь, что это не то, что делает NServiceBus)

Может кто-нибудь объяснить мне, как NServiceBus делает это?

Ответы [ 3 ]

12 голосов
/ 19 августа 2010

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

  1. По умолчанию MSMQ гарантирует только то, что ваша локальная инфраструктура msmq получила сообщение.Не требуется, чтобы принимающие серверы были в сети.Это может быть включено, хотя (см. Ответ Джона ниже)

  2. Это IMO один из ключевых пунктов продажи NSB.Возможность использовать транзакции, которые охватывают как локальную очередь, так и ваше хранилище данных (т. Е. Распределенную транзакцию), имеет решающее значение для обеспечения согласованности.То есть, если что-то не получается, в вашем хранилище данных ничего не сохраняется, и сообщение откатывается и повторяется без необходимости что-либо делать.

  3. То же, что и # 1.Единственная гарантия - каждый подписчик в конечном итоге получит опубликованное сообщение.Блокировочные вызовы не выполняются, так как до тех пор, пока у вас есть свободное место на диске и серверу публикации вызов будет возвращен немедленно.

Надеюсь, что это поможет!

1 голос
/ 19 августа 2010

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

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

Точка 1 - неполная.Транзакционные сообщения дают вам это, ЕСЛИ вы используете Журналирование Отрицательного и Положительного Источника с Очередими Мертвых букв и Таймеры TTRQ / TTBR.Затем вы можете точно определить, что произошло с сообщением - было ли оно отклонено, доставлено ли оно, было ли оно обработано.

...