Обработка рабочей нагрузки С# .NET в стиле обработки очереди заданий, примеры идей?

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

В далеком прошлом я использовал IBM MQ/Series — это работало для финансового приложения, но, насколько я помню, было довольно тяжелым.

Я знаю о MSMQ, и я также слышал о многих других.

Но сначала мой контекст

У меня есть серверное веб-приложение C#/.NET, которое передает данные и т. д. в интерфейс Javascript (в основном jQuery и т. д.) через вызовы AJAX и т. д. У меня есть ситуация, когда определенное действие включает загрузку некоторых файлов, настройку нескольких записей записи в базе данных, отправка сообщений некоторым пользователям по электронной почте и т. д. Поэтому, конечно, я не хочу делать этот процесс «онлайн»/«в режиме реального времени» из-за возможной задержки по времени, и я уверен, что накладные расходы на веб-сервере/базе данных и т. д.

Итак, учитывая тип «сообщений», которые мне нужно ставить в очередь и обрабатывать, что было бы (я не должен просто говорить здесь просто, я думаю!) хорошей отправной точкой? следует ли мне работать с MSMQ и/или сервисным брокером SQL 2008, или чем-то вроде ZeroMQ, или мне просто нужно создать свою собственную облегченную службу очереди рабочей нагрузки?

Я снова понимаю, что не видя полной картины, трудно давать полные рекомендации, однако любые стартовые баллы с благодарностью принимаются!

Дэйвид


person Dav.id    schedule 17.11.2010    source источник


Ответы (1)


Не пытайтесь сделать свой собственный, пожалуйста! Есть так много вещей, которые нужно учитывать, что вы, скорее всего, потратите на это больше времени, чем на остальную часть вашего проекта.

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

person Gerrie Schenck    schedule 17.11.2010
comment
Ха! согласен .. поверьте мне, писать свой собственный тип очереди не очень хорошая мысль ... спасибо за публикацию! - person Dav.id; 17.11.2010
comment
+1 - Поскольку мне пришлось поддерживать и поддерживать собственную систему очередей, я настоятельно рекомендую вместо этого использовать MSMQ. - person Jeromy Irvine; 17.11.2010