Реализация простого кэша локальной памяти в экземпляре Azure

Я ищу простой способ реализовать локальное хранилище памяти, которое можно использовать в экземпляре Azure .NET.

Я рассматривал совместное кэширование Azure и, кажется, поддерживает все мои требования:

  1. Работайте как с веб-ролями, так и с рабочими ролями

  2. Реализовать простой LRU

  3. Хранить кешированные объекты в памяти (ОЗУ)

  4. Позвольте мне определить размер кэша в процентах от общего объема оперативной памяти компьютера.

  5. Хранить кеш на том же компьютере, что и веб-/рабочая роль (режим совместного размещения).

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

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

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

Конфигурация локального кэша?

Я видел параметр конфигурации в кэшировании Azure для включения локального кэша - но все еще кажется, что машины могут общаться друг с другом (например, во время промаха кеша). Эта конфигурация также требует ttlValue и objectCount, и я хочу, чтобы TTL был «навсегда», а количество объектов было «пока вы не заполните весь кеш». Такое ощущение, что указание maxInt в обоих случаях кажется неправильным.

Как насчет простой статической переменной?

Когда я действительно думаю об этом, все это кэширование Azure кажется излишним для того, что мне нужно. В основном мне просто нужна статическая переменная на уровне приложения/роли.. за исключением того, что это не работает для требования № 6 (разные домены приложений). Требование № 4 также немного сложнее реализовать в этом случае.

Мемкэш

Я думаю, старый добрый memcached делает именно то, что я хочу. Проблема в том, что я использую Azure как PaaS и не хочу администрировать свои собственные виртуальные машины. Я не думаю, что смогу установить memcached на свои роли.. [ОБНОВЛЕНИЕ] Кажется, на моих ролях можно запустить memcached локально. Есть ли более элегантное «родное» решение без использования самого memcached?


person talkol    schedule 18.08.2013    source источник
comment
Какие вещи вы кешируете? Имейте в виду, что только строки и несколько специальных объектов (потоки, домены приложений) действительно являются общими для доменов приложений, все остальное сериализуется и десериализуется при пересечении границ домена приложения. Затем есть MarshalByRefObject, который не является общим, но вызовы из разных доменов приложений направляются в его собственный домен приложения. Вы можете создать словарь MarshalByRef, поместить его в статический файл и использовать в доменах приложений.   -  person Anton Tykhyy    schedule 19.08.2013
comment
@AntonTykhyy Я хочу кэшировать простые объекты JSON (плоский словарь из примерно 8 строк, каждая из которых составляет около 100-200 байт). Можете ли вы указать мне где-нибудь пример реализации вашей идеи, это звучит идеально   -  person talkol    schedule 19.08.2013
comment
Я не мог найти ни одного. Однако вам это действительно нужно? Точка входа роли выполняется в другом процессе, чем веб-роль (1), но если ваша веб-роль имеет только один сайт, она выполняется в одном домене приложения. Просто поместите свой статический кеш в Global.asax, и все будет готово.   -  person Anton Tykhyy    schedule 19.08.2013
comment
@AntonTykhyy Моя веб-роль имеет несколько обработчиков (файлов ashx), и я не уверен, работают ли они в разных доменах приложений или нет. Я предпочитаю не рисковать и делать предположения   -  person talkol    schedule 19.08.2013


Ответы (2)


Вы, безусловно, можете установить memcached на роли Web и Worker. Стив Маркс написал в блоге запуск memcached в облачной службе Azure несколько лет назад, до Присутствовали функции виртуальной машины. Это старый пост, поэтому вы можете столкнуться с другими способами решения этой проблемы, такими как использование запускать задачи вместо метода OnStart в RoleEntryPoint и т.д.

person MikeWo    schedule 18.08.2013
comment
Спасибо, я не знал, что memcached возможен. Знаете ли вы о более родном решении, кроме memcached для этой цели? - person talkol; 18.08.2013
comment
Ничего из коробки. Совместно расположенная функция кэширования Windows Azure, о которой вы уже упоминали, является наиболее близкой. Вы можете написать свою собственную службу, которая запускается локально и представляет собой кеш памяти, используя пространство имен кэширования .NET Framework, к которому можно получить доступ между доменами приложений, но это кажется излишним, если вы можете использовать уже созданную структуру кеша. Я не спрашивал, почему вам на самом деле не нужен распределенный кеш, потому что я предполагаю, что у вас есть свои причины. Я бы хотя бы проверил задержку, если это то, о чем вы беспокоитесь. - person MikeWo; 18.08.2013

Я использовал «бесплатные» версии SQL Server для локального кэширования, и они отлично работали. Это зависит от того, что вы делаете, но я использовал как SQL Server Express, так и Compact для хранения целых небольших наборов статических данных для сайта фэнтези-футбола, который я написал, включая статистику за 5 лет. Они очень хорошо работали даже на небольших/средних экземплярах Azure из-за небольшого размера.

http://blogs.msdn.com/b/jerrynixon/archive/2012/02/26/sql-express-v-localdb-v-sql-compact-edition.aspx

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

person Bart Czernicki    schedule 20.08.2013