Zookeeper в качестве in memory cache.

zookeeper медленный

А насколько, если не секрет? Как я понял из того, что нагуглил - он явно быстрее субд.

В Zookeeper внутри Paxos. Скажи зачем тебе он для кеша

Примерно 1000 запросов в секунду выдаст? Больше в обозримом будущем вряд-ли потребуется. Я бы вообще не заморачивался с кешированием, но субд периодически может быть загружена по уши записью данных и не хочется ее грузить дополнительно.

Для кеша он мне и не нужен. Просто есть необходимость вытащить некоторое количество данных из базы во что-то побыстрее, а zk уже используется в проекте. Не хочется плодить лишних сущностей.

Он совсем не для того, так как в нем Paxos, то будет сильнейший боттлнек на запись. Но в плане чтения он все же может быть очень быстрым, как любое in-memory хранилище

лучше поставь нормальный кеш и не парь мозга себе - быстрее будет :)

Не хочется плодить лишних сущностей.

сказал боцман и засунул ложку с едой в задницу...

Ну, количество операций записи именно сессий/справочников измеряется единицами в минуту. Это не публичный сервер, а внутреннее решение. Т.е. одновременных клиентов максимум сотня, веб-сессии могут вообще месяцами могут висеть без изменений. Справочники тоже редактируются крайне редко. Возможно что будет довольно много данных из очереди (от приборов, система - что то типа мониторинга), но они пойдут напрямую в базу и в кеше им делать совершенно нечего.

Т.е. одновременных клиентов максимум сотня, веб-сессии могут вообще месяцами могут висеть без изменений.

зачем для этого вообще нужно хранить сессии в выделенном хранилище? sticky sessions вполне достаточно же.

а справочники вообще обычно можно не синхронизировать, т.е. хранить себе в локальной памяти и пусть протухают по таймауту.

зачем для этого вообще нужно хранить сессии в выделенном хранилище? sticky sessions вполне достаточно же.

Не, не достаточно, там лежит кое-какие данные, которые нужны в.т.ч. серваку. Ну и клиенты не должны отцепляться от сервера в случае его перезагрузки, т.е. какое то хранилище нужно.

а справочники вообще обычно можно не синхронизировать, т.е. хранить себе в локальной памяти и пусть протухают по таймауту.

Думал над таким вариантом, в принципе подойдет конечно, но вариант с быстрым кэшем мне пока нравится больше.

Не, не достаточно, там лежит кое-какие данные, которые нужны в.т.ч. серваку. Ну и клиенты не должны отцепляться от сервера в случае его перезагрузки, т.е. какое то хранилище нужно.

ну значит ты нагородил какую-то ерунду и теперь пытаешься её разрулить при помощи ещё одной ерунды.

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

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

Нет, не вариант. Данные нужны именно серверу. Например в сессии лежит список устройств, которые клиент выкинул на экран (скриншот: http://s11.postimg.org/kkyizq6ub/Untitled.png ) по которому определяется, какие данные ему надо гнать через вебсокет (все гнать не вариант, устройств может быть дофига).

Нет, не вариант. Данные нужны именно серверу.

ну так клиент их при установке соединения и пошлет. даже если сервер выключится - клиенту нужно будет перестанавливать соединение => перепосылать куки и список устройств в них. никакого волшебства.

Клиент то их пошлет, не вопрос. А дальше мне их надо будет куда-то положить. Чтобы при отправке данных на клиент сервер смог их откуда-то достать. Т.е. данные пушатся с сервера, через вебсокет, _без_ предварительного запроса с клиентской стороны. Можно перевязку клиента с устройствами хранить конечно в базе или просто в оперативке, но имхо в сессии проще.

Выдаст. 10000 выдаст легко, а если на ssd поставить, то больше. Только учти, что он не любит когда база растет и когда между нодами большие задержки. Стоит рассчитывать на максимум 300-400 мегабайт на базу, дальше придется танцевать с бубном вокруг настроек и мириться с проседанием производительности.

Кстати если у тебя в одном zk будет жить кафка и твой проект, то надо быть очень аккуратным. Если zk поставишь раком, то кафка может уйти в расколбас с потерей данных в итоге.

Если zk поставишь раком, то кафка может уйти в расколбас с потерей данных в итоге.

Угу, я уже заметил капризность всего этого хозяйства. Оно у меня например периодически после остановки в дебагере отваливается так, что только перезапуск сервера (моего сервера, который kafka consumer) помогает.

Кстати, если уж с кафкой приходилось работать, еще вопрос - можно ее consumer-у скормить при инициализации готовый коннект к zk? Желательно без грязных хаков типа раскопок в ее исходниках.

Стоит рассчитывать на максимум 300-400 мегабайт на базу

Там данных справочников максимум 20-30 мегабайт в среднем наберется, вряд ли больше. Еще сессии могут метров 10 занять. Так что вроде влезаю.

Кстати, если уж с кафкой приходилось работать, еще вопрос - можно ее consumer-у скормить при инициализации готовый коннект к zk? Желательно без грязных хаков типа раскопок в ее исходниках.

Есть SimpleConsumer на базе которого можно написать своего. С ZookeeperWTFConsumer слишком много проблем, я его использовать не смог.

Еще сессии могут метров 10 занять

В zk одна нода не может хранить больше 1M данных.

В zk одна нода не может хранить больше 1M данных.

Я в курсе. 20-30 мб это всего справочников. Естественно они будут раскиданы по разным нодам.

Есть SimpleConsumer на базе которого можно написать своего. С ZookeeperWTFConsumer слишком много проблем, я его использовать не смог.

Ок, ясно, спасибо