Задача проектирования: общий доступ, синхронизация, доступ к данным в приложении ... лучший подход?

Question

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

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

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

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

Это лучший подход? Или я должен использовать базу данных для контроля блокировки? Как избежать узких мест в моем приложении?

Советы очень ценятся.

Answer 1

Это зависит от многих факторов. Когда вы ссылаетесь на кеш, вы имеете в виду стандартный кеш, предоставляемый Asp.Net?

Абсолютно важно, чтобы у вас всегда была самая свежая информация, или если два запроса сделаны для распределения, это нормально, чтобы они были распределены двум наименее занятым пользователям в момент запроса?

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

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

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

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

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

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

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

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

Answer 2

Используйте базу данных для управления этим.

Если по какой-то причине в будущем вам потребуется расширить возможности использования веб-фермы, у вас не возникнет проблем. Однако если вы кешируете данные и работаете локально, это может вызвать интересные вещи.

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

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

Answer 3

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

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

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

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

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