Кэширование в кластерной среде

Question

Кэширование ваших данных в коде вашего приложения, как правило, является хорошей идеей по многим причинам. Мы некоторое время занимаемся этим в нашей общей среде, которая включает ColdFusion, .NET и PHP. Однако, поскольку мы делимся этой средой со многими другими группами разработчиков в нашей организации, время простоя значительно больше, чем мы (или наши клиенты) оцениваем.

Поэтому наши веб-администраторы переходят к внедрению новой среды. В этой среде они добавляют уровень QA между текущими средами Dev и Prod. Кроме того, чтобы увеличить время безотказной работы, они кластеризуют машины как на уровне контроля качества, так и на уровне производительности.

Это все замечательно по многим причинам. Единственная область, где я вижу проблему, связана с кэшированием. Там будет два (или более в зависимости от количества узлов) наборов кеша. Как вы можете себе представить, это создает следующую потенциальную проблему. Кэш-память одинакова на узлах A и B. Пользователь 1 обновляет данные, и, таким образом, кэш-память обновляется на узле A. Пользователь 2 приходит на запрос данных, но находится на узле B и, следовательно, получает старые данные.

Есть ли у них какие-либо передовые методы, как с этим справиться?

Могу ли я внести какие-либо изменения в мой код?

Существуют ли настройки сервера, которые могут быть реализованы?

Answer 1

При использовании конфигурации ColdFusion Multiserver с кластеризованными экземплярами ColdFusion вы можете использовать репликацию сеанса в кластере, но использовать ее экономно, поскольку кэшированные данные постоянно сериализуются и направляются на другие серверы кластера. Вы можете сериализовать сложные данные (CFWDDX) и сохранить их в базе данных, затем сохранить первичный ключ в области сеанса, чтобы реплицировать, где найти запись, и, возможно, флаг, указывающий, что кэшированные данные были изменены, что заставило бы другие серверы обновить свой кеш из базы данных.

Answer 2

Два основных подхода к кешированию контента: 1) централизация и 2) репликация.

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

Если вы говорите только о небольшой группе веб-серверов, то вам нужна простая настройка централизации. Я бы порекомендовал сервер memcached для каждой среды (который PHP поддерживает ). Таким образом, в вашей модели оба узла A и B будут использовать кэшированные данные из нового узла: узла C.

Репликация является более масштабируемым решением, но оно также значительно сложнее в реализации. Но вам нужно набрать огромный объем трафика, чтобы пройти этот маршрут (например, facebook, youtube, wikipedia), поэтому я сомневаюсь, что вам нужно беспокоиться об этом.

Answer 3

Если вы используете ColdFusion 9, вы можете использовать новое встроенное кэширование, которое реализует ehcache под капотом. В кластерной среде очень легко настроить реплицированный кластерный кеш, который использует RMI (буквально всего несколько строк XML). Смотрите мою серию о кешировании в ColdFusion 9 здесь:

http://www.brooks -bilson.com / блоги / грабят / index.cfm / Кэширование

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

Answer 4

Существует реализация cf клиента java memcached, которая позволит вам использовать memcached для простого и прямого кэширования из coldfusion.

http://memcached.riaforge.org/

Я бы очень сильно проголосовал за memcached, даже если бы вам пришлось запускать его на одном кластере веб-серверов, вы бы получили преимущество единого расположения кэша для элементов данных и избыточности кластера. *

Answer 5

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

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