Дизайн/архитектура системы Лучший подход

Question

У меня есть система, которая имеет 3 общие части, чтобы помочь моему описанию.

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

2) черный ящик - один процесс пункта в то время, путем введения в списке необходимых элементов из базы данных, как pipe, где u помещается в набор условий, значений для одного элемента и возвращает результаты для одного обработанного элемента.

3) WINDOWS SERVICE - для извлечения данных из базы данных, вводимых в черный ящик, с помощью предопределенных интервалов сохраняет результаты из черного ящика в базу данных. Служба может находиться на другом сервере в базе данных. Будет ошибка журнала и продолжить, если возникнет ошибка.

В среднем, служба Windows должна обработать около 5000 предметов, и для обработки 5000 предметов потребуется черный ящик около 1,5 секунды.

Моих вопросов:

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

b) Следует ли сохранить отдельный элемент сразу после обработки? Или он должен дождаться завершения обработки партии до сохранения? Поскольку сохранение каждого отдельного элемента после обработки является хорошим, когда системы внезапно терпят неудачу в середине процесса, по крайней мере обработанные сохраняются, но за счет производительности из-за его 5000 вызовов веб-службы?

Любые советы по оптимальному решению?

Cheers

Answer 1

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

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

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

   • это предполагает, что вы будете сохранять данные для каждого элемента

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

   • Если он падает, вы потеряете все несохраненные данные.

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

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

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

   table ItemsProcessStatus -- feel free to improve upon the name 
   int orderID (auto increment) 
   int itemID (fk to items) 
   datetime pulledForProcessing null 
   datetime finishedProcessing null 
   ..etc 
   

2. окна обслуживания работает на таймер, скажем, один раз каждые Х минут и тянет limit(Y) элементы для обработки. это отметит флаг pulledForProcessing с отметкой времени в таблице ItemsProcessStatus.

   • Вы хотите, чтобы вытащить пункты, где растянутая дата является недействительной [а также те, которые были вытащены, но не завершены, и старше Z минут (я обычно забрать 15 до 30 минут)]

   • Будьте осторожны с процедурой, которая тянет их. Вы должны использовать замки

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

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

   • Я положил их в очереди THREADSAFE <> (не следует путать с MSMQ). Цикл рабочих потоков, вытягивание из очереди, обработка элемента в черном поле, а затем обновление базы данных.

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

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

5. Когда служба остановлена, закончить обработку всех элементов, обрабатываемые и обновить их в db.

   • Для всех предметов, которые не были отправлены в черный ящик, вы отмените их в таблице процессов, установив pulledForProcessing на null.
     
     
6. если ваш сбой службы, вы не «потерять» много данных. предметы, которые не получили опознавательных знаков будут втянуты еще раз, когда они старше определенного возраста (таблица процессов)

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

Answer 2

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

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

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

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