Это вопрос архитектуры. У меня есть идея иметь сервер с огромной памятью, который используется как держатель кеша больших объектов. Клиенты отправляют «Действия» на этот сервер (например, «Поиск лица» с возрастом имущества < 13). И тогда эта машина (чтобы усложнить ситуацию было бы неплохо иметь больше экземпляров этого сервера и распространять список лиц для каждого экземпляра, чтобы хранить половину данных, и оба экземпляра будут работать над запросом - стиль MapReduce), затем возвратит Лица, соответствующие критериям. Другие «действия» будут представлять собой определенный кеш-флеш, или сказать «Обновить персонаж с идентификатором от 3 до экземпляра ...» и т. Д.Вопрос архитектуры для реализации сервера кеша
Угадайте, что самое лучшее, что делает это Oracle Coherence, но мне интересно, имеет другие решения с открытым исходным кодом или идеи.
Одно из простых решений заключается в использовании EhCache с Hibernate, но я не знаю, какой протокол я бы использовал, чтобы превратить это в сервер (я вижу, что вы отправляете действия как вызывающие методы на «сервере», а методы возвращают список лиц, соответствующих запросу). Возможно, можно использовать простой RMI. Я еще не убежден, что я хотел бы получить более проверенное решение, структуру, также было бы неплохо иметь переход на резервный ресурс, автообнаружение и сокращение карты. Наверное, я могу обернуть GridGain поверх своего решения EhCache и решить это? Будет ли это чрезмерным (я могу придерживаться только одного экземпляра этого сервера datagrid).
Другой вариант - это Терракота. Дело в том, что я почти не знаю о Terracotta, только чтобы вы могли делиться данными между экземплярами. Если я добавляю элементы из процесса в распределенный кеш, а в другом процессе есть локальная копия кеша, и реплицируются только различия? Это было бы прекрасно для того, чтобы каждый процесс запрашивал локальный кеш, и это было бы очень быстро, но это также означает значительную память, используемую в клиентских процессах.
Итак, у кого-нибудь есть идеи?
Спасибо.