Таблица базы данных MSMQ v

Существующий процесс изменяет поле статуса записи о бронировании в таблице в ответ на ввод пользователя.

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

Эта операция очень похожа на очередь. Каковы преимущества и компромиссы использования MSMQ по таблице SQL в этой ситуации и почему я должен выбирать один из них?

Это наше программное обеспечение, которое добавляет и обновляет записи в таблице.

Это новая работа (служба Windows), которая будет выполнять асинхронную обработку. Это должно быть "всегда вверх".

Ответ 1

Существует несколько причин, которые обсуждались на форуме Fog Creek: http://discuss.fogcreek.com/joelonsoftware5/default.asp?cmd=show&ixPost=173704&ixReplies=5

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

Можно только вставить запись в таблицу, когда вы можете подключиться к базе данных.

Настольный подход лучше, когда требуется подход рабочего процесса, и процесс будет проходить через различные этапы, и эти этапы должны сохраняться в БД.

Ответ 2

Если скорость создания записей бронирования низкая, у меня будет второй процесс, периодически проверяющий таблицу для новых заказов.

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

Если база данных сильно загружена или вы получаете много конфликтов блокировки с двумя процессами чтения и записи в том же регионе таблицы бронирования, а затем рассмотреть вопрос о введении MSMQ.

Ответ 3

Мне также нравится этот ответ от le dorfier в предыдущем обсуждении :

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

Спасибо, ребята, за все ответы. Наиболее полезно.

Ответ 4

С MSMQ вы также можете легко разгрузить работу на другой сервер, изменив расположение очереди на другую машину, а не на сервер db.

Кстати, с SQL Server 2005 в БД встроена очередь. Его называют SQL Service Service Broker. См.: http://msdn.microsoft.com/en-us/library/ms345108.aspx

Ответ 5

Также см. предыдущее обсуждение.

Ответ 6

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

Ответ 7

Недавно я расследовал это, поэтому хотел упомянуть о моих выводах. Расположение базы данных по сравнению с вашим приложением является важным фактором при выборе варианта.

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

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

Когда к базе данных обращались через приличное подключение к Интернету, вставка строки в базу данных была в 6 раз медленнее, чем запись в MSMQ.

Итак:

Локальная база данных - DB быстрее, в противном случае MSMQ.

Ответ 8

Вместо того, чтобы делать необработанные вызовы MSMQ, может быть проще, если вы реализуете свое устройство как компонент COM + с очередью и делаете вызовы в очереди с вашего клиентского приложения. В конце концов, асинхронная служба все еще использует MSMQ в фоновом режиме, но ваш код будет намного понятнее и проще в использовании.

Ответ 9

Я, вероятно, поеду с MSMQ или с ActiveMQ. Я бы предположил (предполагая, что вы рассматриваете MSMQ, что используете окна, с технологией MS), просматриваете WCF или используете MS-SQL 2005+ с триггером, который вызывает код .net для запуска вашей обработки.

Ответ 10

Service Broker был представлен в SQL 2005, и он разработан для очень быстрой обработки сообщений, поскольку процесс относительно прост (я считаю, что его корни были в триггерах). Если вас беспокоит масштабируемость, в SQL 2008 они выпустили независимый исполняемый файл обработки для разделения обработки с SQL Server (в стандартном Service Broker все контролируется экземплярами SQL Server).

Я бы определенно подумал об использовании Service Broker над MSMQ, но это зависит от ваших ресурсов SQL Development/DBA и их знаний.

Ответ 11

Помимо ответа Митча, некоторые другие сценарии: 1. Каждое ваше сообщение имеет свою собственную дату, чтобы инициировать действие, это также можно сделать с помощью MQ, но в этом случае я предпочитаю хранить его в db, поскольку он более управляем; 2. подписчику необходимо отфильтровать сообщение, а затем обработать его часть, это также можно сделать с помощью LINQ, зависит от того, насколько сложным является фильтр, подход db лучше, потому что я могу использовать linq для EF, чтобы сделать сложный запрос легко; 3. Для развертывания я хочу полностью автоматизировать процесс развертывания, чтобы DB был лучшим выбором для меня. Я не большой поклонник ручных конфигураций.