Где должен жить мой демон кэширования?

TL; DR — должен ли простой кеш-кластер для хранения сеансов (с использованием memcache или redis) жить на серверах приложения (то есть вместе с nginx и php) или в своем собственном отдельном экземпляре ec2 (например, elasticache или настроенный экземпляр ec2)?

Я использую Amazon OpsWorks для настройки инфраструктуры своего веб-приложения. Я склоняюсь к реализации кэша сеанса через экземпляры memcache, установленные на самом уровне приложения, а не как собственный экземпляр ec2. Например:

                 [ Load Balancer ]
                /        |        \
[ App Layer 1 ] – [ App Layer 2 ] – [ App Layer 3 ]  * /w memcache or redis

vs.

                 [ Load Balancer ]
               /         |         \
[ App Layer 1 ]   [ App Layer 2 ]   [ App Layer 3 ]
               \         |         /
                [ Cache Server(s) ]   * ElastiCache or custom ec2 /w memcache or redis

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

Есть ли причина, по которой я не хочу запускать Redis или Elasticache вместе с моим стеком сервера приложений nginx/php? Возможно, это затрудняет автоматическое масштабирование или мониторинг производительности?


amazon-web-services caching redis memcached aws-opsworks
person mikegreiling    schedule 05.04.2014    source источник
comment
+1 за навыки построения диаграмм ASCII!   -  person Itamar Haber    schedule 06.04.2014

Ответы (2)


arrow_upward
1
arrow_downward

Основная причина наличия кэша на сервере приложений — это вопрос стоимости. Это та же идея, что ваша БД не должна находиться на том же сервере, что и ваш веб-сервер или сервер приложений.

Если у вас небольшое приложение, вы, вероятно, сможете разместить все свои ресурсы на одном компьютере, но тогда ваша способность восстанавливаться после любого типа сбоя (и "все терпит неудачу"), вы либо потеряете данные, либо часть службы будет отключена для некоторых ваших пользователи.

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

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

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

person Guy    schedule 06.04.2014

arrow_upward
2
arrow_downward

Два основных недостатка 1-го решения:

  • Вы будете вынуждены прилипнуть к сеансу.
  • Вы связываете события масштабирования приложения и кеша.

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

person Itamar Haber    schedule 06.04.2014
comment
Спасибо за это! Я выбрал другой ответ, потому что он был более подробным, но мы оба очень полезны! - person mikegreiling; 07.04.2014
comment
Np - просто хотел добавить свои 2 цента;) - person Itamar Haber; 07.04.2014