Хорошая стратегия для очереди сообщений?

Question

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

Приложение включает в себя несколько отдельных веб-приложений - некоторые из них по сути являются службами WCF, которые получают данные, а некоторые являются сайтами, позволяющими пользователям управлять данными. Кроме того, в фоновом режиме должна быть работающая служба, которая будет обрабатывать данные различными способами.

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

Тем не менее, я хочу разработать хороший набор технологий для этого, имея в виду, что в конечном итоге я перейду на Azure и захочу свести к минимуму объем переделок, которые мне понадобятся при миграции в облако. Azure имеет встроенный компонент Queue, который выглядит идеально для моих нужд. Что я хотел бы сделать, так это создать что-то, что будет имитировать это настолько близко, насколько это возможно.

Похоже, есть несколько вариантов (я использую .NET в Windows, с серверной частью SQL Server 2005) - я нашел следующие:

• MSMQ
• Сервисный брокер SQL Server
• Мой собственный, используя таблицу базы данных и несколько сохраненных процедур

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

Заранее спасибо,

John

Answer 1

Если вы имеете в виду Azure, возможно, вам следует начать прямо с Azure, поскольку API и семантика значительно различаются между очередями Azure и любой из MSMQ или SSB.

Быстрое 3048-метровое сравнение MSMQ с SSB (я оставлю пользовательскую таблицу как очередь вне сравнения, так как это действительно зависит от того, как вы ее реализуете) ...

• Развертывание : MSMQ - это компонент Windows, SSB - компонент SQL. SSB требует экземпляр SQL для хранения любого сообщения, поэтому отключенным клиентам необходим доступ к экземпляру (может быть Express). MSMQ требует развертывания MSMQ на клиенте (часть ОС, но не обязательно).
• Программируемость : MSMQ предлагает полноценный, поддерживаемый канал WCF. SSB предлагает только экспериментальный канал WCF на http://ssbwcf.codeplex.com
• Производительность : SSB будет значительно быстрее, чем MSMQ в транзакционном режиме. MSMQ будет работать быстрее, если позволить работать в нетранзакционном режиме (наилучшее усилие, неупорядоченный, доставка)
• Запрос : очереди SSB можно выбрать SELECTE-ed (просмотреть любое сообщение, полная мощность SQL JOIN / WHERE / ORDER / GROUP), очереди MSMQ можно просмотреть (только следующее сообщение)
• Восстанавливаемость : очереди SSB интегрированы в базу данных, поэтому они резервируются и восстанавливаются вместе с базой данных, сохраняя состояние согласованности с состоянием приложения. Очереди MSMQ резервируются в подсистеме резервного копирования файлов NT, поэтому для обеспечения синхронизации (связности) резервного копирования базы данных очереди и необходимо приостановить.
• Транзакции (поскольку каждая очередь / очередь всегда сопровождается обновлением базы данных): SSB полностью интегрирован в SQL, поэтому удаление из очереди и постановка в очередь являются операциями локальной транзакции. MSMQ - это отдельная TM (диспетчер транзакций), поэтому очередь / очередь должна быть операцией распределенной транзакции, чтобы зарегистрировать как SQL, так и MSMQ в транзакции.
• Управление и мониторинг : оба одинаково плохи. Никаких инструментов.
• Коррелированные сообщения обработка: SSB может блокировать обработку коррелированных сообщений конкурирующими потоками с помощью встроенного Блокировка группы переговоров .
• Event Driven : SSB имеет Активация для запуска хранимых процедур, MSMQ использует Windows Activation service. Аналогичный. SSB, тем не менее, обладает возможностями самораспределения нагрузки благодаря взаимодействию WAITFOR (RECEIVE) и MAX_QUEUE_READERS.
• Доступность : встраивание SSB в историю высокой доступности SQL Server позволяет работать как в кластерной среде, так и в среде зеркального отображения базы данных. MSMQ рассказывает только о кластеризации Windows. Зеркальное отображение базы данных намного дешевле, чем кластеризация в качестве решения высокой доступности.

Кроме того, я бы добавил, что SSB и MSMQ значительно различаются по уровню предлагаемого примитива: примитив SSB - это разговор , а примитив MSMQ - сообщение . Подумайте, семантика TCP против UDP.

Answer 2

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

Имей свой путь
Чтобы свести к минимуму переработку ваших приложений, абстрагируйте доступ к очередям за интерфейсом, а затем предоставьте реализацию для транспорта очереди, с которым вы в конечном итоге решите пойти. Когда пришло время перейти на Azure или другой транспорт очереди, вы просто предоставляете новую реализацию вашего интерфейса.

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

Грубая идея может быть:

interface IQueuedTransport
{
  void SendMessage(XmlDocument);
  XmlDocument ReceiveMessage();
}

public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}

Возможно, вы не строите общий транспорт для очередей, а именно то, что соответствует вашим потребностям. Если вы работаете с Xml, передайте xml. Если вы работаете в байтовых массивах, передайте байтовые массивы. :)

Удачи!
Z

Answer 3

Использовать Win32 Почтовые ящики . Они будут надежны на одном сервере, просты в реализации и не требуют дополнительного программного обеспечения.