Настройка Redis для приложения с интенсивным чтением
Тайм-аут соединения Redis даже после обновления до elasticache m4.xlarge Мы столкнулись с таймаутом подключения. Размер нашего кеша едва ли составляет 1,5 Гб. Мы использовали экземпляр m4.large, и было около 150-200 подключений к экземпляру. Мы попытались добавить две реплики чтения, но все равно не было уменьшения. Мы попытались переместить к кластеру, к сожалению, клиент redis ruby не поддерживает кластеризацию. Что можно сделать
Redis настолько же мощный, насколько и ограниченный дизайн. Он обеспечивает отличную производительность с мощными операциями и типами данных ... но он является однопоточным и монолитным по дизайну, а это означает, что независимо от того, сколько ядер у вашего компьютера, Redis будет использовать только одно. Если вашему приложению требуется больше операций в секунду, чем может обработать один процесс Redis, ваш единственный выбор - распределить нагрузку между несколькими процессами / серверами Redis.
Кластер Redis решает эту проблему самостоятельно, разделяя нагрузку внутри себя, жертвуя некоторым ключом такие функции, как конвейерная обработка и операции с несколькими клавишами, но требующие совместимых клиентских библиотек.
Стандартный Redis предоставляет два способа масштабирования емкости чтения, но оба требуют определенных усилий на стороне клиента: Чтение реплик и сегментирование данных между несколькими мастерами Redis (и реплики чтения для каждого мастера). В первом случае вы должны сбалансировать операции чтения между всеми вашими репликами (многие клиентские библиотеки предоставляют встроенную поддержку для этого). Во втором сценарии ваше приложение отвечает за процесс сегментирования данных и отправляет трафик в каждый «кластер» Redis, оценивая функцию распределения перед каждой операцией.
В любом случае масштабирование емкости чтения с помощью Redis - нетривиальная задача. Я надеюсь, что все эти варианты помогут прояснить ситуацию.