Redis: что это, где применяется и как установить на Ubuntu

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

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

Ключ ведёт не только к строке

В простом хранилище «ключ — значение» приложение записывает значение под уникальным именем, например product:42. По этому имени Redis находит данные без поиска по таблице. Значением может быть не только текст: Redis поддерживает хеши, списки, множества, упорядоченные множества, потоки и другие структуры.

Выбор структуры определяет доступные операции. Счётчик удобно хранить числом и увеличивать атомарной командой, то есть без промежуточного состояния, видимого другим клиентам. Очередь можно построить на списке или Redis Streams, но требования к подтверждению и повторной обработке нужно проектировать отдельно.

Имена ключей создаёт само приложение. Двоеточия в session:8f2a не образуют настоящие каталоги — это лишь удобное соглашение, по которому различают назначение ключей.

Как работает кеш и почему ему нужен срок жизни

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

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

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

Не задавайте один TTL всему проекту механически. Для публичного справочника допустимы минуты, для одноразового кода — срок его действия, а сессия пользователя требует согласованной политики безопасности.

Сессии и очереди предъявляют другие требования

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

Очередь передаёт работу фоновому обработчику: отправить письмо, создать изображение, пересчитать отчёт. Здесь важно не только быстро добавить элемент, но и подтвердить обработку, повторить задачу после сбоя и не выполнить опасную операцию дважды. Простого списка может быть недостаточно. Для критичной очереди сравните Redis Streams и специализированные брокеры по требуемым гарантиям.

Redis полезен, когда его структуры совпадают со способом доступа к данным. Он не отменяет реляционную базу вроде PostgreSQL, которая лучше выражает связи, ограничения и сложные выборки.

Установите Redis из официального репозитория

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

Установите инструменты для определения выпуска Ubuntu, загрузки и проверки ключа:

sudo apt-get update
sudo apt-get install lsb-release curl gpg

apt-get update обновляет список пакетов, а следующая команда устанавливает три утилиты. При ошибке подписи или недоступном репозитории остановитесь и проверьте дату системы, DNS и текущие APT-источники; не отключайте проверку подписей.

Теперь сохраните ключ репозитория и сделайте файл читаемым для APT:

curl -fsSL https://packages.redis.io/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg

curl -f завершится ошибкой при неуспешном HTTP-ответе, а gpg --dearmor преобразует ключ в формат keyring. Если целевой файл уже существует, gpg запросит подтверждение замены. Не перезаписывайте его, пока не убедились, что это ключ того же официального репозитория.

Добавьте репозиторий для кодового имени установленной Ubuntu:

echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/redis.list
sudo apt-get update
sudo apt-get install redis

Команда lsb_release -cs подставляет кодовое имя выпуска, а signed-by связывает источник с конкретным ключом. После установки проверьте службу и версию:

sudo systemctl is-active redis-server
redis-server --version
redis-cli ping

Ожидаются active, строка версии и ответ PONG. redis-cli без дополнительных параметров соединяется с 127.0.0.1:6379. Если служба не запустилась, посмотрите sudo journalctl -u redis-server -n 100 --no-pager и исправьте указанную причину до настройки приложения.

Убедитесь, что Redis не смотрит в интернет

Проверьте слушающий адрес на VPS. Команда читает таблицу TCP-сокетов и отбирает порт 6379, не меняя службу или firewall:

sudo ss -lntp '( sport = :6379 )'

Для приложения на том же сервере ожидается 127.0.0.1:6379 и, возможно, локальный IPv6-адрес ::1. Адрес 0.0.0.0:6379 означает приём соединений на всех IPv4-интерфейсах. В таком состоянии сначала закройте порт firewall и настройте привязку, а уже затем запускайте приложение.

Основной файл конфигурации пакетной установки обычно находится в /etc/redis/redis.conf. Посмотрите активные строки, не раскрывая пароли в выводе:

sudo grep -E '^(bind|protected-mode|port)[[:space:]]' /etc/redis/redis.conf

Для локального сценария bind должен включать loopback, protected-mode — иметь значение yes, а порт обычно равен 6379. Перед изменением сделайте копию файла с датой, исправьте только необходимые строки, затем проверьте журнал после перезапуска. Не публикуйте содержимое конфигурации целиком: в ней могут находиться секреты.

Если клиент находится на другом сервере, не используйте публичный Redis «с паролем» как единственную защиту. Ограничьте маршруты и firewall конкретной частной сетью, настройте TLS и ACL — списки пользователей и разрешённых команд. ACL предпочтительнее одной общей учётной записи, потому что приложение получает только нужные права.

Проверьте ключ, TTL и удаление

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

redis-cli SET tutorial:greeting "hello" EX 60
redis-cli GET tutorial:greeting
redis-cli TTL tutorial:greeting

SET сохраняет строку, а EX 60 задаёт срок жизни 60 секунд. GET сначала должен вернуть hello. TTL покажет оставшиеся секунды, -2 означает, что ключа уже нет, а -1 — что у существующего ключа не задан срок.

Удалить учебный ключ раньше срока можно командой:

redis-cli DEL tutorial:greeting

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

Выберите режим сохранения данных

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

Эти режимы можно сочетать. Выбор зависит от роли:

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

Реплика помогает пережить отказ узла, но повторяет удаление и повреждение данных. Она не заменяет резервную копию. Следите за памятью: когда лимит исчерпан, выбранная политика вытеснения может удалять ключи или Redis начнёт отклонять запись. Общая диагностика памяти и OOM разобрана в отдельном руководстве.

Подключайте приложение отдельной учётной записью

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

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

Перед production проверьте четыре сценария: Redis работает; ключ отсутствует; соединение медленное или разорвано; сервер перезапущен и данные восстановлены согласно выбранной политике. Только успешный PING не подтверждает, что архитектура выдержит эти случаи.

Источники

• Redis: установка Redis Open Source
• Redis: безопасность сервера
• Redis: сохранение данных
• Redis: типы данных