#caching #architecture #appfabric
#кэширование #архитектура #appfabric
Вопрос:
Наше веб-приложение развернуто на веб-ферме (более 20 серверов). Сайт имеет огромный трафик (миллионы просмотров страниц в день). В первом выпуске это приложение использует CacheManager от EntLib (кэширование блоков приложений Entreprise). Мы называем это «Кэш локального сервера». Есть много преимуществ, но у нас все еще есть серьезный недостаток: каждый сервер управляет своим собственным кэшем и доступом к базе данных (не распределенной).
Вот почему мы пытаемся реализовать функцию кэширования AppFabric, чтобы сократить количество обходов базы данных. Одной из основных проблем, с которыми мы сталкиваемся, является синхронизация данных :
- при использовании GetAndLock / PutAndUnLock (он же распределенная блокировка) время отклика страницы сильно снижается
- с помощью Get / Put простой блокировки на стороне сервера у нас так много запросов к локальному кэшу; никаких преимуществ.
Итак, каковы ограничения кэширования для крупномасштабных веб-сайтов?
Спасибо,
Ответ №1:
Я бы сказал, кэшировать данные только для чтения, насколько это возможно. Для этого вы можете использовать службу кэширования AppFabric. Вы можете настроить кластер, скажем, из 5 серверов кэширования. Затем все ваши 20 интерфейсных серверов будут взаимодействовать с этим кластером кэша, чтобы получить кэшированные данные. Вы также можете воспользоваться преимуществом хранения наиболее часто используемых данных непосредственно во внешнем интерфейсе (локальный кэш). Например, наша конфигурация такова:
- интерфейс (16 компьютеров) с LocalCache для хранения 150 000 наиболее часто используемых элементов
- кластер кэша (4 машины) с режимом высокой доступности, хранящий все данные в кэше
- база данных (1 компьютер) со всеми данными
Для данных, которые вы хотите обновить, становится сложнее. Каждый раз, когда вы вводите блокировки, ваша производительность будет снижаться.
Комментарии:
1. Это типичная архитектура для appfabric cache. Мне нужна стратегия обновления данных: внутри запроса страницы, когда срок действия данных истек? Фоновым потоком (и сохранение грязной копии моих данных для возврата)? С помощью выделенной службы (но как обрабатывать бизнес-правила)? Я перечислил эти возможные решения. Есть идеи?
Ответ №2:
Как я упоминал в MSDN, немедленная согласованность обходится дорого. Вы должны пойти на некоторые компромиссы в согласованности или выложить много денег, чтобы сразу добиться согласованности. Использование изолированной модели чтения / записи, которую мы обсуждали в MSDN, наряду с очередями, вероятно, обеспечит вам наилучшую производительность / согласованность с точки зрения затрат. Несколько уровней кэша, предложенных Дэвидом, также превосходны, в зависимости от вашей общей архитектуры / дизайна. Использование вашей собственной локальной реализации кэша in-proc или localhosted также предлагает большую ценность — я сам не поклонник локального кэша OOTB от AppFabric.
—ab