Кэширование с помощью нескольких серверов

Question

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

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

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

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

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

Answer 1

Я думаю, что нашел относительно хорошее решение.

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

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

Answer 2

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

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

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

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

Answer 3

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