VPS

Как установить Redis на Ubuntu и настроить локальный кеш приложения

Установка Redis из пакетов Ubuntu, локальный доступ, ограничение памяти, проверка TTL и подключение приложения без публикации порта.

Оперативная память и блоки кешированных данных рядом с сервером

Redis помогает быстро хранить и получать небольшие значения в памяти: результаты частых запросов, временные данные и состояние приложения. Он полезен, когда измерения показывают повторяющуюся работу, которую можно не выполнять при каждом обращении. Установка Redis сама по себе не ускоряет WordPress, Python или Node.js: приложение должно действительно использовать это хранилище.

Ниже установим Redis из репозитория Ubuntu 24.04, ограничим доступ локальным сервером и проверим ключ с временем жизни. В этой конфигурации Redis используется как восстанавливаемый кеш, а основная информация остаётся в PostgreSQL, MySQL или другом надёжном источнике.

Когда Redis нужен, а когда можно обойтись без него

Хороший пример — блок популярных публикаций, который одинаков для многих посетителей и пересчитывается тяжёлым запросом. Приложение записывает готовый результат на короткий срок, затем читает его из Redis. После окончания TTL результат можно построить заново.

Плохой первый шаг — ставить ещё одну службу, когда причина задержки неизвестна. Если сайт тратит время на огромные изображения или внешний HTTP-запрос, кеш базы может не повлиять на проблему. Начните с диагностики медленной загрузки.

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

Подготовить сервер

Понадобятся Ubuntu 24.04 и пользователь с sudo. Приложение и Redis в этом примере находятся на одном VPS. Если сервера ещё нет, воспользуйтесь выбором первого VPS и подготовкой учётной записи.

Перед установкой проверьте ресурсы и существующие службы:

free -h
df -h /
command -v redis-server
sudo ss -ltnp '( sport = :6379 )'

Если Redis уже используется приложением, сначала выясните его назначение. Перезапуск и смена политики памяти затрагивают существующих клиентов. На нашем стенде Redis до начала опыта отсутствовал; WordPress работал отдельно.

Установить пакеты Ubuntu

sudo apt update
sudo apt install redis-server redis-tools
sudo systemctl enable --now redis-server
systemctl is-active redis-server
redis-server --version

Репозиторий дистрибутива может предоставлять другую ветку, чем последний выпуск с сайта Redis. Это два разных канала установки. Для базового локального кеша ниже использованы пакеты Ubuntu: на стенде установилась Redis 7.0.15. Фактическую версию проверяйте командой, а обновления безопасности — средствами используемого репозитория.

Не смешивайте без необходимости несколько установок, контейнер и сторонний systemd unit на одном порту. Ошибка запуска из-за занятого 6379 не решается повторной установкой ещё одного пакета.

Оставить доступ только с этого VPS

Сохраните копию /etc/redis/redis.conf, затем откройте файл через sudoedit /etc/redis/redis.conf. Проверьте действующие строки:

bind 127.0.0.1 -::1
protected-mode yes

127.0.0.1 и ::1 — loopback-адреса. Минус перед ::1 допускает запуск при недоступном IPv6-адресе. Не добавляйте 0.0.0.0 ради подключения из другого контейнера или с домашнего компьютера: это меняет сетевую границу всей службы.

После изменения:

sudo systemctl restart redis-server
systemctl is-active redis-server
sudo ss -ltnp '( sport = :6379 )'
redis-cli PING

Ожидаемый ответ последней команды — PONG. В выводе ss не должно появиться прослушивание всех внешних интерфейсов. Не открывайте Redis в UFW для этого локального сценария.

Loopback не заменяет разграничение прав между разными доверенными пользователями самого сервера. Для общей инфраструктуры проектируйте ACL, отдельные экземпляры, сетевую изоляцию и, где требуется, TLS. Пароль без ограничения сетевого доступа тоже не является достаточным основанием публиковать Redis в интернет.

Настроить память именно для кеша

На учебном сервере для небольшого кеша заданы:

maxmemory 128mb
maxmemory-policy allkeys-lru

Это пример, а не универсальная рекомендация размера. Redis требует память и вне полезных значений: на структуры, соединения, служебные данные и некоторые операции сохранения. Значение maxmemory не равно жёсткому верхнему пределу всей RAM процесса. Оставьте запас операционной системе, веб-приложению и базе данных.

allkeys-lru позволяет вытеснять ключи при нехватке выделенной памяти. Поэтому эта настройка подходит для данных, которые приложение умеет восстановить. Для важных очередей или сессий неожиданное вытеснение может быть недопустимым. В таком случае нужны отдельные решения по политике памяти, отказам записи и сохранности.

Перезапустите службу и проверьте, что применились нужные значения:

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

В нашем опыте получены 134217728 байт и allkeys-lru. Проверка состояния после перезапуска важнее предположения, что редактор сохранил правильный файл.

Проверить запись, чтение и TTL

Используйте отдельное учебное имя ключа:

redis-cli SET hostfera:demo:cache "hello" EX 60
redis-cli GET hostfera:demo:cache
redis-cli TTL hostfera:demo:cache

Первая команда возвращает OK, вторая — hello, третья — оставшееся время в секундах. -2 означает, что ключ уже отсутствует, -1 — что у существующего ключа нет срока действия. По истечении минуты проверьте:

redis-cli EXISTS hostfera:demo:cache

Ожидается 0. Чтобы завершить опыт раньше, удалите только свой учебный ключ командой redis-cli DEL hostfera:demo:cache. Не используйте для очистки примера FLUSHALL или FLUSHDB: они затрагивают другие данные.

На стенде отдельно проверен короткий TTL: значение читалось до истечения срока и отсутствовало после него. Redis отвечал только на loopback-адресах.

Redis отвечает PONG, хранит ключ с TTL и слушает loopback
Проверка Redis на Ubuntu 24.04: PING, ключ, TTL и локальные интерфейсы, 03.11.2026.

Подключить приложение

Для приложения на том же хосте адрес подключения обычно начинается с redis://127.0.0.1:6379. Добавьте клиентскую библиотеку через зависимости проекта, задайте тайм-аут соединения и чтения и определите поведение при недоступности кеша.

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

В FastAPI или Node.js храните адрес в настройках приложения, а не в шаблоне страницы. В Docker 127.0.0.1 внутри контейнера относится к самому контейнеру; переносить хостовый адрес туда без изменения сетевой схемы нельзя. Сначала разберите контейнерную архитектуру.

Продумать сохранность и наблюдение

У Redis есть механизмы RDB и AOF, но они не превращают любой кеш в готовую резервную копию. Для восстанавливаемого кеша можно принять потерю значений. Для других задач нужно отдельно определить допустимую потерю данных, режим сохранения и проверку восстановления.

Основную базу продолжайте копировать независимо: например, по инструкции резервирования PostgreSQL. Перезапуск Redis не должен становиться способом проверки восстановления единственной копии важных данных.

После подключения смотрите INFO memory и INFO stats: рост памяти, вытеснений, ошибок соединений, попаданий и промахов кеша. Сравнивайте не только процент попаданий, но и время ответа приложения и нагрузку основной базы. Кеш считается полезным, когда измеримый сценарий ускорился, а свежесть данных и работа сайта сохранились.

Первоисточники

Нашли неточность?

Сообщите адрес статьи и фрагмент через контакты редакции.