Вопрос по asp.net, architecture – Является ли разделение уровней веб-сайтов и баз данных с помощью MSMQ необходимым или чрезмерным?

8

Я собираю простой веб-элемент управления asp.net, который в результате публикации формы ajax вставляет запись в базу данных MSQL.

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

Решение, которое пришло мне в голову, - заставить веб-элемент управления поместить сообщение в очередь MSMQ, а служба Windows на сервере периодически читать очередь и выполнять пакетную вставку.

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

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

Любой совет будет очень признателен

Большое спасибо

Пит

Ваш Ответ

2   ответа
10

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

То, что вы должны или даже можете сделать, зависит от ряда факторов.

Основной фактор: должны ли ваши абоненты видеть ответы на свои запросы синхронно?

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

Однако, если допустимо, чтобы вызывающим абонентам был отправлен ответ о том, что их запрос будет обработан в автономном режиме (и любой требуемый ответ также будет отправлен в автономном режиме), то использование очереди определенно принесет пользу вашей общей архитектур

Первая вещь, которая будет выиграна, это проблемы доступности внешнего интерфейса.

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

Однако, уменьшая объем серверной работы, выполняемой IIS (запись в локальную очередь действительно дешева по сравнению с вызовом базы данных), вы также снижаете вероятность сбоя на основе доступности.

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

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

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

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

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

Сильный ответ Хью, большое спасибо за это. Подтвердил то, что я подозревал, и многое другое! Pete Field
+ 1 для отличного сравнения и объяснения вариантов. Большое спасибо Jens H
2

но, безусловно, связана с большими затратами и сложностью. Это должно быть тщательно сбалансировано. Из 2 компонентов (веб-приложение и БД) вам теперь придется разрабатывать, поддерживать и контролировать 4 компонента (веб-приложение, БД, пакетный сервис, MSMQ). Вы сказали, что веб-сервер и сервер БД - это одна и та же машина, что странно, учитывая ваши требования к производительности. Завтра может потребоваться разместить веб-приложение, пакетный сервис и БД на 3-х отдельных машинах. Теперь MSMQ также включает сеть. Еще одна вещь, которая может пойти не так. Многопоточный пакетный процессор также не прост, что если вам придется обрабатывать каждое сообщение в последовательности, в которой они были сгенерированы (по крайней мере, для данного объекта), логика может стать сложной.

Если возможно измерить оба решения и решить.

Я согласен с тобой по поводу мониторинга накладных расходов, да, есть еще вещи для мониторинга. Тем не менее, полностью отвергаю, что подход имеет большую сложность. Решение с высокой степенью связи сложнее в развертывании и обслуживании. Слабосвязанные решения проще, хотя есть больше движущихся частей. Каждая часть имеет четкую ответственность. Кроме того, многопоточная пакетная служба не требуется, только служба прослушивания однопоточной очереди. Согласитесь, что масштабирование может повлиять на порядок доставки, но это неизбежно. Также MSMQ является частью подсистемы Windows и не нуждается в "разработке". tom redfern

Похожие вопросы