Является ли Zookeeper подходящим для кэширования объектов?

Question

Разработка облачной системы с учетом масштабируемости, означающей, что система состоит из служб на основе REST по функциональным границам (usermgmt, ordermgmt, customermgt и т. Д.), Каждая из которых имеет свою собственную базовую базу данных и в зависимости от нагрузки, ее предположительно, что мы можем вращаться несколько экземпляров, например, службы ordermgmt. Когда служба ordermgmt обрабатывает запрос на добавление заказа (от имени «клиента»), он сделает запрос REST к службе customermgmt для проверки клиента и т. Д.

Поскольку объект клиента не изменился очень часто мне интересно, подходит ли что-то вроде ZooKeeper для кэширования экземпляра конкретного клиента, чтобы несколько экземпляров службы customermgmt могли допросить, прежде чем попасть в базу данных. Я просмотрел различные списки Zookeeper, но не вижу, чтобы кто-то использовал его для кэширования объектов. Кажется, что рекомендуемый размер znode байтов составляет приблизительно 1K, что делает его непригодным для хранения обезвоженного объекта. Также нет поддержки для GC или LRU из коробки, поэтому мне также нужно будет добавить это.

Если нет Zookeeper, более подходящие предложения? Мы используем Hibernate как ORM, но у нас нет большого опыта работы с ним, и хотя он поддерживает кеши первого и второго уровней, я не уверен, что они работают распределенным/реплицированным способом в нескольких экземплярах службы ,

Благодаря Скотт

Answer 1

На самом деле вы можете установить множество различных технологий, распределенных или нет, так как L2-кэш Hibernate.

• EHCache
• Memcached
• JCache
• Hazelcast
• Infinispan
• Терракотовая
• GigaSpaces XAP
• Gemfire
• Когерентность

Последние, называемые datagrids, обычно не являются бесплатными, и я не думаю, что вам нужен целый набор данных только для кеша l2.

Я никогда не использовал его, но я не думаю, что Zookeeper был использован для использования в качестве распределенного кеша.

Answer 2

Zookeeper не подходит для кеша объектов.

Zookeeper хранит всю базу данных в памяти в куче java. Как только куча java будет превышать Gigabyte или так, вы начнете сталкиваться с проблемами с gc-паузами. Это особенно хлопотно с zookeeper, потому что узлы zookeeper постоянно посылают звуковые сигналы друг другу, и, если достаточно хватать сердцебиений, когда узел занят gc'ing, запускаются выборы лидера, что приводит к тому, что кластер переходит на второй план.

Другая проблема с использованием zookeeper в качестве кеша заключается в том, что все узлы в кластере zookeeper будут иметь те же данные, которые вам обычно не нужны для кеша.

С этими ограничениями ваши 3 сервера, каждый с 8 гигабайтами, могут обслуживать общий рабочий набор ~ 1 гигабайт. Лучше использовать memcache или одну из других системных списков Sebastien.