Комментарии 11
Для горизонтального масштабирования Redis-а мы используем client side sharding (RedisArray). Для хранения кеша как раз подходит
а чтобы не было лишних двух инструментов, можно погуглить keydb fork и сделать мультимастер минут за 15 :)
Для тех, кто в теме, больше 3k qps у кого-то держит редис базёнкой гигов в 20 с мультитредом на один инстанс, или я его совсем готовить не умею?
Для тех, кто в теме, больше 3k qps у кого-то держит редис базёнкой гигов в 20 с мультитредом на один инстанс, или я его совсем готовить не умею?
У нас 700k qps на ~10GB базе, так что возможно что-то таки неправильно настрояно
Redis один или стадо? Если стадо, то в связанном кластере или каждый redis сам по себе?
Присоединюсь к коменатору выше по поводу keydb — почему его не рассматривали вообще? Ну предположим страшно — переписанный redis и непонятно чего можно ожидать.
А как же решения проверенные временем для ванильного redis:
1) github.com/Netflix/dynomite — невероятно мощная штука по возможностям — сделать такое на ванильном redis невозможно в принципе — отказоустойчивость, репликация между dc и т.д.;
2) github.com/twitter/pelikan (новая инкарнация github.com/twitter/twemproxy) — так же отличное решение, с чуть менее широким кругом применения
А как же решения проверенные временем для ванильного redis:
1) github.com/Netflix/dynomite — невероятно мощная штука по возможностям — сделать такое на ванильном redis невозможно в принципе — отказоустойчивость, репликация между dc и т.д.;
2) github.com/twitter/pelikan (новая инкарнация github.com/twitter/twemproxy) — так же отличное решение, с чуть менее широким кругом применения
redis не нужен. Можно применить memcached и получить на одном хосте в 10 раз большую производительность при меньших задержках, не настраивая костылей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Горизонтальное масштабирование и отказоустойчивость Redis для сервисных служб DirectumRX