Назад | Перейти на главную страницу

Настройка Redis для тяжелого чтения приложения

Тайм-аут соединения Redis даже после обновления до elasticache m4.xlarge Мы столкнулись с тайм-аутом соединения. Размер нашего кэша едва ли составляет 1,5 ГБ. Мы использовали экземпляр m4.large, и было около 150-200 подключений к экземпляру. Мы попытались добавить две реплики чтения. и все равно снижения не было. Мы пытались перейти на кластер, но, к сожалению, клиент redis ruby ​​не поддерживает кластеризацию. Что можно было сделать

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

Кластер Redis решает эту проблему самостоятельно, сегментируя нагрузку внутри, жертвуя некоторыми ключевыми функциями, такими как конвейерная обработка и многоклавиатурные операции, но требует совместимых клиентских библиотек.

Стандартный Redis предоставляет два способа масштабирования емкости чтения, но оба требуют определенных усилий на стороне клиента: реплики чтения и сегментирование данных между несколькими мастерами Redis (и реплики чтения для каждого мастера). В первом случае вы должны сбалансировать операции чтения между всеми вашими репликами (многие клиентские библиотеки предоставляют встроенную поддержку для этого). Во втором сценарии ваше приложение отвечает за процесс сегментирования данных и отправляет трафик в каждый «кластер» Redis, оценивая функцию распределения перед каждой операцией.

Как бы то ни было, увеличение емкости чтения с помощью Redis - нетривиальная задача. Я надеюсь, что все эти варианты помогут прояснить ситуацию.