Как лучше всего использовать глобальный кэш с резервной копией на веб-сервере ASP.NET? - PullRequest
0 голосов
/ 28 октября 2009

Я должен кешировать иерархию объектов в памяти из соображений производительности, которая отражает простую таблицу базы данных со столбцами (ObjectID, ParentObjectID, Timestamp) и просмотр CurrentObjectHierarchy. Я запрашиваю CurrentObjectHierarchy и использую хеш-таблицу для кэширования текущих родителей каждого объекта для быстрого поиска идентификатора родительского объекта по заданному идентификатору объекта. Запрос к таблице базы данных и построение кеша - это в среднем операция 77 мс, и в идеале это обновление происходит только при вызове метода в моем API базы данных, который изменит иерархию (добавление / удаление / переопределение объекта).

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

Изначально я хранил кеш в статической переменной в C # dll, совместно используемой различными веб-приложениями. Проблема, конечно, заключается в том, что, хотя к статическим переменным можно обращаться через потоки, они не могут быть доступны через процессы, что является проблемой, когда задействовано несколько веб-приложений (возможно, работающих в отдельных пулах приложений). В результате ... синхронизированные, поточно-ориентированные изменения в кэше иерархии объектов в одном приложении не отражаются в других приложениях, даже если они используют одну и ту же кодовую базу.

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

Потенциальные места, которые я рассматривал:

  • Какой-то тип глобального хранилища объектов в самом IIS, доступный из любого потока в любом приложении в любом пуле приложений (если такое место существует. Есть ли?)
  • Отдельный настраиваемый веб-сервис, управляющий эксклюзивным кешем.

Сейчас я думаю, что ЛУЧШЕЕ решение - это интеграция SQL CLR , потому что:

  • Я могу сохранить свой текущий дизайн, используя статические переменные
  • Это отдельный сервис, который уже существует, поэтому мне не нужно писать собственный
  • Он будет работать в одном процессе (SQL Server), поэтому существующая синхронизация на основе блокировки будет работать нормально
  • Кэш будет устанавливаться как можно ближе к структурам данных, которые он представляет!

Я бы встроил методы обхода иерархии в DLL-библиотеку SQL CLR, чтобы можно было сделать один вызов SQL, где я обычно выполняю обычный вызов метода. Все это зависит от SQL Server, запущенного в одном процессе, и от загрузки CLR в этот процесс, что, как мне кажется, имеет место. Что ты думаешь об этом? Можете ли вы увидеть что-то явно не так с этой идеей, которую я могу пропустить? Разве это не потрясающая идея?

EDIT: После более тщательного изучения кажется, что разные приложения ASP.NET на самом деле выполняются в одном и том же процессе, но изолируются доменами приложений. Если бы я мог найти способ обмениваться данными и синхронизировать их между доменами приложений, это было бы очень полезно. Я сейчас читаю о .NET Remoting.

1 Ответ

0 голосов
/ 28 октября 2009

Microsoft работает над структурой распределенного кэширования: Скорость . Однако последний выпуск является версией CTP3, поэтому он может быть не готов к работе ...

...