Может ли кто-нибудь сказать мне, нужен ли для этого сценария SQL Server Service Broker?

Мой первый вопрос о переполнении стека, поэтому, пожалуйста, полегче. У меня есть давно работающее приложение Windows, которое постоянно обрабатывает команды сервера sql. У меня также есть веб-интерфейс, который пользователи иногда используют для обновления той же базы данных. Я заметил, что иногда (в зависимости от того, что обрабатывает приложение Windows в данный момент), если пользователь отправляет что-то в базу данных, я получаю исключения из памяти на сервере. Я понимаю, что мне нужно еще немного покопаться и оптимизировать код. Однако я не могу позволить серверу выйти из строя и ожидаю, что в будущем я буду разрешать все больше и больше пользователей во внешнем интерфейсе. Что мне действительно нужно, так это система, которая будет ставить запросы пользователей в очередь (они не критичны по времени) и обрабатывать их, когда база данных будет готова.

Я использую экспресс SQL 2012.

Является ли SQL Service Broker лучшим решением, я также изучил MSMQ.

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

Ваше здоровье


sql-server msmq service-broker
person user3688632    schedule 29.05.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это зависит от того, где вы выполняете работу с сохранением и/или вычисления. Если вы выполняете тяжелую работу в своем приложении Windows, то использование очереди Service Broker не будет иметь смысла, поскольку все, что вы будете делать, это получать сообщение из очереди Service Broker в вашем приложении Windows, выполнять вычисления и / или запросы из приложения Windows, а затем сохранение результатов в базе данных: поскольку ваша база данных уже находится под нехваткой памяти, это кажется ненужной дополнительной нагрузкой, поскольку вы могли бы так же легко поставить в очередь и получить сообщение из MSMQ (или любого другого постановка в очередь технологии).

Однако, если вы выполняете всю работу в базе данных, а ваше приложение Windows просто действует как служба сортировки — например, принимает запрос и передает его хранимой процедуре для выполнения действия — тогда, возможно, стоит использовать очереди Service Broker: потому что они уже работая в контексте базы данных, они могут быть очень эффективными при сохранении и запросе данных.

Вы также хотели бы использовать режимы отказа, в зависимости от того, можете ли вы позволить себе потерять какие-либо сообщения. Чтобы обеспечить сохранение сообщений в MSMQ, вы должны использовать Обмен транзакционными сообщениями: Service Broker более эффективен при обработке очереди транзакций, чем MSMQ (поскольку он имеет встроенную поддержку транзакций, в отличие от MSMQ, который должен использовать DTC, что увеличивает накладные расходы), но если объем сообщений невелик, это не может быть проблемой.

person stuartd    schedule 03.06.2014