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

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

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

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

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

queue_1 => processor_1
queue_2 => processor_2

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

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

Изменить

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


azure queue azure-sql-database azure-queues
person Community    schedule 04.05.2011    source источник
comment
Итак, что мне не хватает? Я бы предположил, что вам не хватает всего смысла использования правильной очереди событий. Создание очереди событий с использованием базы данных кажется глупым, когда очереди событий уже являются первоклассными продуктами. Почему бы не использовать MS-MQ и избавить себя от лишней боли?   -  person S.Lott    schedule 04.05.2011
comment
@S. Лотт: Я бы сказал, что всегда есть причина хранить очереди и данные в одном магазине. Единообразное резервное копирование / восстановление, устранение двухфазной фиксации с каждой операцией (DTC между хранилищем сообщений и хранилищем данных), один продукт для развертывания / устранения неполадок / администрирования, одно решение HA / DR, которое сбрасывает хранилище сообщений и хранилище данных вместе в согласованное состояние, все это и многое другое делают очень убедительные доводы в пользу очередей внутри базы данных. Учитывая, что почти каждое сообщение начинается в результате операций с данными и заканчивается обновлением данных, события являются данными, и они принадлежат друг другу.   -  person Remus Rusanu    schedule 04.05.2011
comment
@ S.Lott: 1) У меня нет MSMQ, так как я развертываю его в Azure. 2) У MS-MQ много собственной боли.   -  person    schedule 05.05.2011
comment
@tferreira: Вы спросили, что вам не хватает. Похоже, у вас отсутствуют очереди Azure: msdn.microsoft.com/en-us/library /dd179363.aspx. Пожалуйста, обновите вопрос, чтобы объяснить, почему вы не используете очевидное решение.   -  person S.Lott    schedule 05.05.2011
comment
@ S.Lott: Потому что это не очевидно. Очереди Azure имеют ряд ограничений, не последним из которых является целостность транзакций. Сколько решений вы использовали для очередей Azure? Сколько используют очереди базы данных. Я ищу людей, у которых есть реальный опыт в этом деле. Спасибо.   -  person    schedule 05.05.2011
comment
@tferreira: Все очереди базы данных, которые я видел, были ужасными, ужасными. Действительно плохо. Почему вы говорите, что в очередях Azure отсутствует целостность транзакций? Можете ли вы обновить вопрос этой дополнительной информацией, чтобы было понятно, почему вы их не используете?   -  person S.Lott    schedule 05.05.2011
comment
В этом вопросе вы несколько раз упоминали, что очереди Azure не являются транзакционными. Мне любопытно, что вы имеете в виду под этим.   -  person knightpfhor    schedule 05.05.2011
comment
MSMQ предлагает очереди транзакций. В очередях Azure используется механизм тайм-аута, описанный здесь cloudshaper.wordpress.com/2010/11/05/   -  person    schedule 05.05.2011
comment
Обсуждение ограничений очереди Azure abdullin.com/journal / 2010/4/6 /   -  person    schedule 05.05.2011

Ответы (4)


arrow_upward
5
arrow_downward

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

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

person Remus Rusanu    schedule 04.05.2011
comment
Я не уверен, что балансировка нагрузки за счет наличия нескольких очередей будет являться анти-шаблоном, поскольку я просто горизонтально разбиваю таблицу, что является обычным явлением. Конвои WRT и поздние процессоры, я предполагаю, что правильный алгоритм балансировки нагрузки будет распределять публикации по каждой очереди таким образом, чтобы поддерживать их баланс. - person ; 05.05.2011
comment
Если под секционированием вы подразумеваете горизонтальное масштабирование хранилища сообщений, то единственный выход - несколько очередей. Но если вы планируете развернуть несколько очередей в одном магазине (например, в одной базе данных Azure), я придерживаюсь своего мнения, что одна очередь лучше, чем несколько. Масштабируемость отдельной очереди при правильной реализации намного выше, чем может обеспечить одна база данных Azure, поэтому нет никаких причин для создания большего количества очередей. - person Remus Rusanu; 05.05.2011
comment
Хороший ввод. Я учту ваши аргументы. Спасибо за ответ. - person ; 05.05.2011

arrow_upward
1
arrow_downward

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

person gbn    schedule 04.05.2011

arrow_upward
1
arrow_downward

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

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

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

person David Makogon    schedule 04.05.2011
comment
Я изучаю очередь Azure. Однако меня беспокоит тот факт, что они не являются транзакционными. - person ; 05.05.2011
comment
Из понимания основных принципов Azure Queues - да, это действительно полезная ссылка. Имейте это в виду: существует полный официальный .NET SDK, который скрывает все REST API, так что вам не нужно об этом беспокоиться (хотя все еще полезно понимать). Также есть библиотеки для php и Java, а также несколько проектов с открытым исходным кодом для Ruby и python. - person David Makogon; 05.05.2011

arrow_upward
0
arrow_downward

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

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

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

Изменить

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

person regilero    schedule 04.05.2011