Мне нужно выбрать распределенную систему кэширования на уровне данных, которая может соответствовать следующим условиям.
Должен иметь
- Кэши должны выполняться в отдельном процессе и могут вызываться через TCP / UDP. Мы не хотим запускать кэш в том же пространстве памяти JVM, где в данный момент выполняется веб-приложение.
- Кэши должны быть распределены по нескольким серверам кеша, чтобы исключить любую единственную точку отказа.
- Сериализация должна быть прозрачной в большинстве случаев и не должна требовать от разработчиков реализации методов или интерфейсов для каждого отдельного класса, который должен кэшироваться.
- Единый API для всех типов кэша. Разработчикам не нужно изучать несколько API для чтения / записи различных объектных деревьев.
- В конце концов, в соответствии. Быть всегда непротиворечивым - это дорогое предложение, требующее фиксации фазы n для всех узлов кластера. Нам не нужна такая сложная система.
- Отказоустойчивый ака Изящная деградация. Если вся система кеширования выйдет из строя, приложение все равно может работать, хотя производительность при этих обстоятельствах понизится.
- Автоматическое удаление кэша на основе таких конфигураций, как LRU, FIFO и т. Д.
- с открытым исходным кодом и бесплатно. Наличие исходного кода определенно помогает, как показал наш опыт работы с Solr и Active MQ. Мы готовы приобрести коммерческую поддержку, как и в случае с Solr, но сам программный продукт должен быть бесплатным.
- Динамическое членство в кластере. Весь кластер распределенного кэша не должен требовать перезапусков при добавлении или удалении какого-либо узла.
- Высокая надежность. Решение для кэширования должно быть надежным перед лицом проблем с сервером и сетью и может обрабатывать проблемы согласованности данных, которые могут возникнуть из-за сбоев сервера или сети, состязаний при записи и т. Д.
- Высокоэффективный. Представьте, что кэш-память работает даже медленнее, чем Oracle!
- Дополнительные отметки, если сервер кэширования основан на Java, так как именно в этом команда разработчиков наиболее удобна.
- Высокая доступность данных кеша. Это означает, что репликация данных кэша на несколько узлов такова, что потеря одного узла не означает потерю всех кэшированных данных на этом узле. Мы планируем хранить Java Http Session Objects, чтобы мы также могли переносить сессию.
Приятно иметь
- Веб-консоль для мониторинга и управления всеми узлами сервера кэширования или, по крайней мере, API, с помощью которого мы можем создавать предупреждения и уведомления.