Где хранить кэш в SaaS приложении?

Question

[Антон Медведев]

Я разрабатываю SaaS приложение на Symfony2. Система проста: балансер, несколько серверов приложений, и несколько серверов баз данных.

Каждый сервер приложений имеет полную копию приложения, различия только в параметрах.
Есть несколько вопросов:

• Где хранить кэш клиента?
  
• Где хранить файловый кэш app/сache? Отдельно для каждого клиента app/сache/clientN?
  
• Где хранить HTTP кэш? На серверов приложений или узеле балансировки?
  Что делать, если каждый клиент на своем домене?
  
• Где хранить кэш запросов/результатов к базе данных? На сервер БД в памяти (Redis / Riak / Memcached)?
  

Comments

[Дмитрий Полушкин]

Что за слой cache servers?

[Александр Бындю]

Elfet Уточните, пожалуйста, что такое кэш клиента?

И отдельно по каждому пункту: Для чего нужен этот кэш в вашем приложении? Почему эти данные нужно хранить в кэше?

[Антон Медведев]

Александр Бындю: разрабатываю SaaS систему (для примера пусть будет сервис создания сайтов), каждый клиент имеет данные относящиеся только к нему, например каталог товаров, шаблоны, страницы, ...

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

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

Answer 1

[tzlom]

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

HTTP кэш - нужен ли? и опять таки зависит от приложений и количества хитов, если там куча статики одинаковой для всех и её тяжко отдавать - втыкайте между балансировщиком (тяжко отдавать, пускай кеш балансирует тоже) и сервисом (а он будет кеш наполнять)

Файловый кеш - вопрос к тому что за сервис и как оно работает, возможно вообще не нужен, возможно HTTP кеша хватит.

Кеш БД храни в БД (КО в деле)

А вообще сперва рекомендую профилировать количество хитов кеша и объёмы, кеширование не серебрянная пуля, иногда лучше подправить бизнес логику чем ставить кеширование в каждую точку, лучший кандидат в кеш это то, к чему: обращаются часто, по одним и тем же ключам, весит оно не много, меняется редко а вычисляется сложно.