Хорошая стратегия организации очередей сообщений?
После попытки почти каждого включить мою клавиатуру:
C:\Users\Tim>cd ^
Mehr? Desktop
C:\Users\Tim\Desktop>
, Таким образом, это, кажется, ^ ключ.
2 ответа
Если у вас Azure в виду, возможно, вам следует начать прямо с Azure, поскольку API и семнатика значительно различаются между очередями Azure и любыми MSMQ или SSB.
Быстрое сравнение MSMQ и SSB на 3048 метров (я оставлю настраиваемую таблицу - as-queue вне сравнения, поскольку это действительно зависит от того, как вы это реализуете ...)
- Развертывание : MSMQ - это компонент Windows, SSB - компонент SQL. SSB требует, чтобы экземпляр SQL сохранял любое сообщение, поэтому отключенным клиентам нужен доступ к экземпляру (может быть Express). MSMQ требует развертывания MSMQ на клиенте (часть ОС, но необязательная установка).
- Возможность программирования : MSMQ предлагает полноценный поддерживаемый канал WCF. SSB предлагает только экспериментальный канал WCF на http://ssbwcf.codeplex.com
- Performance : SSB будет значительно быстрее, чем MSMQ в транзакционном режиме. MSMQ будет работать быстрее, если он будет работать в режиме без пересылки (максимальное усилие, неупорядоченный, доставка)
- Запрос : очереди SSB могут быть выбраны вверх (просмотр любого сообщения, полная мощность SQL JOIN / WHERE / ORDER / GROUP) , Очереди MSMQ могут быть просмотрены (только следующее сообщение)
- Восстанавливаемость : очереди SSB интегрированы в базу данных, поэтому они копируются и восстанавливаются вместе с базой данных, сохраняя состояние, согласованное с состоянием приложения. Очереди MSMQ копируются в подсистеме резервного копирования файлов NT, поэтому, чтобы резервное копирование было синхронизировано (согласовано), очередь и база данных должны быть приостановлены.
- Транзакции (поскольку каждая постановка / удаление из очереди всегда сопровождается базой данных update): SSB полностью интегрирован в SQL, поэтому удаление из очереди и постановка в очередь являются локальными операциями транзакции. MSMQ - это отдельный TM (диспетчер транзакций), поэтому очередь / удаление из очереди должны быть операцией распределенной транзакции, чтобы зарегистрировать как SQL, так и MSMQ в транзакции.
- Управление и мониторинг : оба одинаково плохи. Никаких инструментов.
- Обработка коррелированных сообщений : SSB может блокировать обработку коррелированных сообщений параллельными потоками через встроенную Блокировку группы разговоров .
- Управляемый событиями : SSB имеет Активация для запуска хранимых процедур, MSMQ использует службу активации Windows . Аналогичный. SSB, тем не менее, имеет возможности самостоятельной балансировки нагрузки из-за способа взаимодействия WAITFOR (RECEIVE) и MAX_QUEUE_READERS.
- Доступность : SSB совмещает историю высокой доступности SQL Server, он может работать либо в кластерной среде, либо в среде зеркалирования базы данных. MSMQ использует только историю кластеризации Windows. Зеркальное отображение базы данных намного дешевле, чем кластеризация в качестве решения высокой доступности.
Кроме того, я бы добавил, что SSB и MSMQ значительно отличаются на уровне примитива, который они предлагают: примитив SSB - это диалог , тогда как примитив MSMQ это сообщение . Подумайте о семантике TCP и UDP.
SSB совмещает историю высокой доступности SQL Server, он может работать как в кластерной среде, так и в среде зеркалирования базы данных. MSMQ использует только историю кластеризации Windows. Зеркальное отображение базы данных намного дешевле, чем кластеризация в качестве решения высокой доступности.Кроме того, я бы добавил, что SSB и MSMQ значительно различаются на уровне предлагаемого ими примитива: примитив SSB - это диалог , а примитив MSMQ это сообщение . Подумайте о семантике TCP и UDP.
SSB совмещает историю высокой доступности SQL Server, он может работать как в кластерной среде, так и в среде зеркалирования базы данных. MSMQ использует только историю кластеризации Windows. Зеркальное отображение базы данных намного дешевле, чем кластеризация в качестве решения высокой доступности.Кроме того, я бы добавил, что SSB и MSMQ значительно отличаются на уровне примитива, который они предлагают: примитив SSB - это диалог , тогда как примитив MSMQ это сообщение . Подумайте о семантике TCP и UDP.
Примитив SSB - это диалог , а примитив MSMQ - это сообщение . Подумайте о семантике TCP и UDP. Примитив SSB - это диалог , а примитив MSMQ - это сообщение . Подумайте о семантике TCP и UDP.Выберите серверную часть очереди, которая работает для вас или лучше подходит для вашей среды. @Remus провел отличное сравнение между MSMQ и SSB. MSMQ будет проще реализовать, но он имеет некоторые заметные ограничения, в то время как SSB будет ощущаться очень тяжелым, поскольку находится на другом конце спектра.
Have It Your Way
Чтобы свести к минимуму переделки из приложения, абстрагируйте доступ к очередям за интерфейсом, а затем предоставьте реализацию для транспорта очереди, который вы в конечном итоге решите использовать. Когда пришло время перейти на Azure или другой транспорт очереди, вы просто предоставляете новую реализацию своего интерфейса.
Вы можете управлять семантикой того, как вы хотите взаимодействовать с очередью, чтобы предоставить единообразный используемый API из ваших приложений. .
Примерная идея может быть такой:
interface IQueuedTransport
{
void SendMessage(XmlDocument);
XmlDocument ReceiveMessage();
}
public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}
Возможно, вы строите не общий транспорт с очередями, а только то, что вам нужно. Если вы работаете с Xml, передайте xml. Если вы работаете с байтовыми массивами, передавайте байтовые массивы. :)
Удачи!
Z