Comments 11
Для горизонтального масштабирования Redis-а мы используем client side sharding (RedisArray). Для хранения кеша как раз подходит
а чтобы не было лишних двух инструментов, можно погуглить keydb fork и сделать мультимастер минут за 15 :)
Для тех, кто в теме, больше 3k qps у кого-то держит редис базёнкой гигов в 20 с мультитредом на один инстанс, или я его совсем готовить не умею?
У нас 700k qps на ~10GB базе, так что возможно что-то таки неправильно настрояно

Redis один или стадо? Если стадо, то в связанном кластере или каждый redis сам по себе?

у меня со стадом всё более-менее, а вот один жрёт 100% CPU, 95% запросов — на мелкую запись, и баз «шардов» оно всё как-то не очень ворочается.

Это redis или keydb? Отношение чтение/запись? Какой средний размер записи в значении ключа? И что за железо?

redis, c keydb всё ок, спасибо, что пнули в нужную сторону, с новым редисом всё приятнее.
95% — запись по ~ 2кб, на чтение сильно на вскидку по ~20мб, в основном list (LRANGE)
обычный xeon, не сильно старый, чё-то из разряда dell 630
Присоединюсь к коменатору выше по поводу keydb — почему его не рассматривали вообще? Ну предположим страшно — переписанный redis и непонятно чего можно ожидать.
А как же решения проверенные временем для ванильного redis:
1) github.com/Netflix/dynomite — невероятно мощная штука по возможностям — сделать такое на ванильном redis невозможно в принципе — отказоустойчивость, репликация между dc и т.д.;
2) github.com/twitter/pelikan (новая инкарнация github.com/twitter/twemproxy) — так же отличное решение, с чуть менее широким кругом применения

1) github.com/Netflix/dynomite валится при redis-benchmark -t ping, но set,get работает.

redis не нужен. Можно применить memcached и получить на одном хосте в 10 раз большую производительность при меньших задержках, не настраивая костылей.

Only those users with full accounts are able to leave comments. Log in, please.