Кеширование с несколькими серверами - PullRequest
0 голосов
/ 28 января 2009

Я создаю приложение с участием нескольких серверов. (4 сервера, на каждом из которых есть база данных и веб-сервер. 1 основная база данных и 3 подчиненных + один балансировщик нагрузки)

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

  1. У меня есть несколько идей для реализации кэширование. Это можно сделать на сервере уровень (локальная файловая система), но проблема заключается в аннулировании кэша файл, когда содержание было обновление на всех серверах: может быть сделано с небольшим кешем время жизни (не эффективно, потому что кеш будет обновляться раньше должно быть большую часть времени)
  2. Это также может быть сделано с помощью обмена сообщениями система (например, XMPP), где каждый Сервер общается друг с другом. Сервер, ответственный за аннулирование кэша отправить просьба ко всем остальным позволить им знаю, что кеш был аннулированной. Задержка наверное больше (займет больше времени для всех знать, что кеш был признан недействительным) но мое заявление не требует атомарного кэша недействительности.
  3. Третий подход - использовать облако система для хранения кеша (вроде CouchDB) но я понятия не имею о производительность для этого. Это быстрее, чем использование базы данных SQL?

Я планировал использовать Zend Framework, но я не думаю, что это действительно актуально (за исключением того, что, вероятно, в других Framework есть какой-то пакет для работы с XMPP, CouchDB)

Требования: постоянный кеш (при перезапуске сервера кеш не должен быть потерян, чтобы избежать сбоя сервера при повторном создании кеша)

Ответы [ 3 ]

5 голосов
/ 28 января 2009

http://www.danga.com/memcached/

Memcached покрывает большинство требований, которые вы выкладываете - чтение на основе сообщений, принятие и аннулирование. Высокая доступность и высокая скорость, но очень малая атомарная надежность (пожертвованная ради производительности).

(Кроме того, memcached работает с такими вещами, как YouTube, Википедия, Facebook, поэтому я думаю, что вполне вероятно, что организации, у которых есть время, деньги и талант для серьезной оценки многих вариантов распределенного кэширования, согласуются с memcached!)

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

1 голос
/ 24 июля 2009

Если вы хотите защитить memcached как хранилище кеша, если вам нужна высокая производительность при низкой нагрузке перезагрузки сервера, почему бы просто не иметь 4 сервера memcached? Или 8? Каждая «перезагрузка» будет соответственно меньше влиять на сервер базы данных.

1 голос
/ 05 февраля 2009

Мне кажется, я нашел относительно хорошее решение.

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

Это означает, что у меня есть локальные файлы кэширования и удаленные действия одновременно. Вероятно, не идеально, но должно работать на данный момент. CouchDB работал слишком медленно, а NFS недостаточно надежен.

...