Синхронизация локального кэша с внешним приложением

Question

У меня есть два отдельных веб-приложения:

1. Приложение "admin", в котором создаются и обновляются данные
2. «Публичное» приложение, в котором отображаются данные.

Информация, отображаемая на «общедоступных», меняется редко, поэтому я хочу ее кешировать.

То, что я ищу, - это "самая простая вещь", чтобы обновить кэш на общедоступном сайте, когда внесены изменения на сайте администратора.

Чтобы добавить сложности, приложение работает в Windows Azure. Это исключает зависимости файлов и кэша sql (по крайней мере, встроенных).

Я запускаю оба приложения в одном экземпляре веб-роли.

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

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

Что я думаю (может быть, немного хакерский, но простой):

1. Иметь действие контроллера на общедоступном сайте, которое очищает кэш в памяти. Меня не беспокоит очистка определенных кэшированных элементов, данные меняются недостаточно, чтобы я беспокоился об этом. Когда приложение «admin» создает кэш, мы отправляем httpwebrequest для очистки кеша на общедоступном сайте.
2. Поскольку база данных является единственным общим ресурсом для двух приложений, просто добавьте таблицу с датой и временем последнего обновления. Публичный сайт будет делать запросы по каждому запросу и сравнивать дату последнего обновления базы данных с тем, который мы будем хранить в памяти. Если он не совпадает, мы очищаем кеш.

Какие-либо другие рекомендации или проблемы с вышеуказанными опциями? Главное здесь - простота и высокая производительность.

Answer 1

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

Если вас не беспокоит то, как скоро обновление будет сделано с сайта администратора до основного сайта, наиболее эффективным и простым (но не самым дешевым) решением является использование Azure AppFabric Cache а затем настройте его для использования локального (в памяти) кэша с коротким временем ожидания (скажем, 10 минут).

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

1. Поиск предмета в локальном кеше
2. Его там нет, поэтому ищите элемент в распределенном кеше
3. Его там тоже нет, поэтому загрузите элемент из постоянного хранилища
4. Добавить элемент в кеш с длительным сроком службы (я думаю, 48 часов по умолчанию)
5. Возврат товара

Шаги 1 и 2 позаботятся о вас библиотекой, остальные биты нужно записать. Любые последующие вызовы в следующие X минут вернут элемент из кеша в памяти. Через X минут он выпадает из локального кэша. Следующий вызов загружает его из распределенного кэша обратно в локальный кеш, и вы можете продолжить.

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

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

Answer 2

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

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

Вероятно, самый быстрый и простой способ - использовать вариант 2, но хранить время последнего обновления в табличном хранилище, а не в базе данных SQL. Чтение в табличное хранилище выполняется очень быстро - под прикрытием это простой HTTP GET.

Answer 3

В конце я использовал BLOB-объекты Azure в качестве зависимостей кэша. Я создал монитор изменений файлов, чтобы опрашивать их на предмет изменений (полная информация http://ben.onfabrik.com/posts/monitoring-files-in-azure-blob-storage).

При внесении изменений в приложение администратора я обновляю BLOB-объект. Когда монитор изменений файла обнаруживает изменение, мы очищаем локальный кеш.