Всем привет! Хочу спросить совета у уважаемого хабрасообщества.
Сейчас в веб-проекте используем для кеша redis, но у него есть недостаток: отсутсвие master-master репликации, что для нас критично. Если по началу можно решить вопрос выделенным сервером под кеш, то в ближайшей перспективе это кажется не очень хорошим решением, да и еще единая точка отказа получается.
Хочу узнать, что уважаемые коллеги посоветуют использовать для кешированя данных веб-приложения имеющее нормальную возможность репликации master-master?
PS очень желательно не писать, что-то вроде «бери riak это круто», все таки хочется примеров успешных внедрений, зарЭзанных проблем и прочее.
Разработчики говорят, что размер объектов не устравивает (хотя это, возможно, и решаемо). От себя (я админ) добавлю, что нужно иметь копию кеша на диске.
Существуют тесты сравнения скорости записи/чтения между mongo и redis, на которые можно опереться? Есть бестпрактис внедрения монго как кеша? (гуглить я умею, если что, просто еще не смотрел эту тему)
Redis sentinel смотрели?
Я сам не пробовал, но они пишут, что в случае падения мастера происходит назначение нового мастера из слейвов. Это, по-идее, сделает решение более отказоустойчивым.
А для масштабирования, можно легко организовать шардинг. Для этого даже есть специальный пакет для python.
Тут вся проблема, что нам выгодно кеш держать вместе с фронтами, и вместе с app-серверами (ну или рядом), и те и другие туда пишут. Соответсвенно если у нас один мастер, то писать все будут в него, что возвращает нас к точке отказа и перегрузке одной машины.
Плюс не уверен, что без проблем удастся объяснить всем хостам приложения, что сменился мастер.
Так что спасибо, но увы, рассмотрели эту тему уже давно и нам не подходит.
Шардинг не решает нашего вопроса, а скорее усложняет реализацию. У нас мало типов данных, которые мы пишем в кеш, соответсенно шардинг нам не обеспечивает гибкости решения при нагрузке.
Главное это отказоустойчивость, и условие, что писать могут в два мастера.
Я почитаю подробнее про шардинг у redis. Наверное я не совсем верно сформулировал свою мысль.
Скажем у меня есть объем кеша в 50 гб разбитый на 2 шарды по 25, одна шарда дохнет — соответсвенно на какой-то момент времени я теряю 25 гигов кеша. Далее решаем этот вопрос двумя слейвам, но это +2 машины за которые я плачу деньги хостеру, но при этом они не участвуют в работе напрямую. Мне легче согласиться с повышенной нагрузкой на кеш, и уборкой части кеша на диск (или в swap), при master-master, чем с включением дополнительных машин. Это на текущем этапе. В будущем эта схема имеет право на жизнь… возможно.
Redis key>value хранилищи по этому по хешам не проблема распределить данные. Мне кажется вы просто не доконца разобрались в вопросе. Посмотрите еще как вариант redis cluster, но он еще не совсем допилен вроде.
Я так понял, что redis cluster будет в 3 версии, а roadmap для трешки я ненашел (то что есть на github как-то не тянет на адекватный), то я пока поостерегусь об redis cluster думать
Мастер-мастер это самое худшее, что может придумать админ.
Как уже сказали — шардинг; если надо копию на харде — редис.
По поводу, мемкеша — что это у вас за кеш, который не помещается в 128меговые слабы?
Простой
