Очереди базы данных и обработка очереди

Question

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

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

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

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

queue_1 => процессор_1queue_2 => процессор_2

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

Тот факт, что я не вижу такого рода реализации ни в одном из моих поисков, заставляет меня думать, что я пропускаюглавный недостаток в этом дизайне.

Редактировать

Эта публикация вызвала дискуссию об использовании таблиц базы данных в качестве очередей по сравнению с MSMQ, очередями Azure и т. д. Я понимаю, что тамдля меня доступно несколько вариантов собственных очередей, в том числе буферы долговременных сообщений в Azure AppFabric.Я оценил свои параметры и определил, что таблиц SQL Azure будет достаточно.Цель моего вопроса состояла в том, чтобы обсудить использование нескольких процессоров в одной очереди против одного процессора в очереди.

Answer 1

См. Использование таблиц в качестве очередей для более подробного обсуждения этой темы. Проблема заключается не только в том, как вы получаете доступ к «очереди», но и в том, как вы ее индексируете. Кластерный индекс должен позволяет выполнять прямой поиск следующей строки для удаления из очереди, иначе вы будете постоянно блокироваться.

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

Answer 2

Как упомянул S.Lott, есть механизмы очереди сообщений, которые вы можете использовать.MSMQ не очень помогает в Windows Azure, но в Windows Azure уже есть надежный механизм очереди.Вы можете легко настроить каждый экземпляр рабочей роли для чтения одного (или нескольких) элементов очереди.После прочтения элемента очереди он становится «невидимым» в течение указанного вами промежутка времени (или 30 секунд, если время не указано).Сообщения в очереди могут быть размером до 8 КБ, и они считаются «надежными» - все хранилище Azure реплицируется минимум 3 раза (как в SQL Azure).

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

Для получения дополнительной информации об очередях Windows Azureпосмотрите Учебный комплект по платформе Azure - есть несколько простых лабораторных работ, которые проведут вас по основам очереди.

Answer 3

Таблицы в виде очередей довольно легко сделать. Смотрите мой ответ SO здесь, пожалуйста: Состояние гонки очереди процесса SQL Server

Answer 4

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

Теперь процесс опросов может умереть, у него может быть много разных проблем, вам все равно, очередь - это место, где заказы безопасны.

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

Редактировать

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