Сократите повторяющуюся работу с базой данных с помощью локального кэша Redis. Redis может хранить в памяти результаты, пригодные для повторного использования, чтобы приложению не приходилось генерировать их заново для каждого запроса. Выигрыш зависит от того, что вы кэшируете, как часто это используется повторно и от остального вашего стека, а не от универсального процента ускорения.
В этом руководстве рассматривается один экземпляр Redis на том же VPS с Debian или Ubuntu, что и его приложение: он устанавливается из репозиториев дистрибутива и доступен только через loopback. Оно включает небольшую функциональную проверку, конфигурацию объектного кэша WordPress и автономный пример на Node.js. Это не руководство по удалённому доступу, высокой доступности или развёртыванию надёжной базы данных.
Прежде чем начать: решите, что будет хранить Redis
Воссоздаваемый кэш содержит данные, которые приложение может восстановить из своей основной базы данных или другого источника. Промахи кэша, истечение срока, вытеснение и перезапуски должны быть безопасными: приложение должно получить исходные данные и перестроить кэш. Определите подходящие TTL и правила инвалидации и не допускайте выдачи кэшированных приватных данных не тому пользователю.
К сессиям, очередям заданий и основным записям могут предъявляться другие требования к потере и восстановлению. Не смешивайте их в экземпляре, который может вытеснять любой ключ. Если данные должны пережить сбои, используйте отдельный экземпляр Redis и продуманную стратегию хранения, резервного копирования и восстановления. Redis Pub/Sub не является надёжной очередью заданий.
Документация Redis по вытеснению объясняет, почему allkeys-lru может удалить любой ключ. И наоборот, noeviction приводит к сбою соответствующих операций записи при достижении лимита памяти; он не обеспечивает резервных копий или долговечности.
Предварительные требования и область применения
- Поддерживаемый релиз Debian или Ubuntu с systemd, SSH-доступ и права sudo.
- Чистый тестовый VPS или согласованное окно обслуживания. Прежде чем что-либо менять, проверьте, нет ли уже сервиса Redis и зависящих от него приложений.
- Объём RAM и диска, рассчитанный под вашу нагрузку, с учётом операционной системы, базы данных, PHP или Node.js, накладных расходов Redis и операций сохранения данных. Универсальной безопасной формулы объёма RAM для VPS не существует.
- Приложение на том же хосте. У контейнеров собственные сетевые пространства имён:
127.0.0.1внутри контейнера обычно не указывает на хост.
Описанные ниже шаги — это процедура, которую нужно проверить на выбранном вами релизе, а не утверждение, что установка протестирована на каждой версии Debian или Ubuntu. Версии пакетов в дистрибутивах различаются; это руководство не обещает конкретную версию сервера Redis.
Шаг 1. Установите пакеты дистрибутива
Обновите индекс пакетов, затем изучите пакеты-кандидаты и репозитории, из которых они берутся:
sudo apt update
apt-cache policy redis-server redis-tools
Продолжайте, только если кандидаты берутся из нужных вам репозиториев Debian или Ubuntu. Если сторонний репозиторий Redis уже настроен, решите этот вопрос с пакетами, прежде чем продолжать. Это руководство не добавляет сторонний репозиторий и не выполняет обновление всех пакетов в системе.
sudo apt install redis-server redis-tools
systemctl status redis-server --no-pager
systemctl cat redis-server
redis-server --version
redis-cli --version
Прежде чем подтверждать, изучите изменения, предлагаемые APT. Пакеты могут автоматически запускать Redis. Юнит сервиса показывает, какой файл конфигурации загружается; обычный путь — /etc/redis/redis.conf, как описано в руководстве Debian по Redis и руководстве Ubuntu по Redis. Если юнит или путь отличаются, используйте фактически установленную конфигурацию, а не создавайте второй экземпляр.
Шаг 2. Оставьте Redis локальным и защитите доступ
Сделайте резервную копию конфигурации перед редактированием. На чистой установке с обычным путём:
sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.before-local-cache
sudoedit /etc/redis/redis.conf
Обновляйте существующие директивы, а не слепо добавляйте дубликаты. Для конфигурации только с IPv4 loopback, используемой в этом руководстве:
bind 127.0.0.1
protected-mode yes
Проверьте включаемые файлы и параметры командной строки сервиса на предмет переопределений. Если вы намеренно сохраняете IPv6 loopback, убедитесь, что это только ::1, а не IPv6-слушатель на всех интерфейсах. Не привязывайтесь к 0.0.0.0 или ::.
Не открывайте порт 6379 в публичный интернет. Проверьте и firewall хоста, и firewall провайдера. Если установлен UFW, sudo ufw status verbose покажет его текущие правила; не включайте и не перенастраивайте firewall вслепую через SSH. Loopback снижает сетевую уязвимость, но не изолирует Redis от других локальных процессов. Пароль не заменяет сетевые ограничения, а AUTH не шифрует трафик, как объясняет руководство Redis по безопасности.
Аутентификация и секреты
Для выделенного экземпляра под одно приложение можно настроить существующую директиву requirepass, задав надёжный уникальный секрет. Задавайте его через защищённый редактор или механизм секретов вашей системы управления конфигурацией; не вставляйте настоящие секреты в команды терминала, записи экрана, систему контроля версий или это руководство. Ограничьте доступ к файлу конфигурации администратором и служебной учётной записью Redis.
Если вы включаете аутентификацию, передайте тот же секрет каждому клиенту, прежде чем включать интеграцию. В примерах ниже используется модель пользователя и пароля по умолчанию; для именованных ACL-пользователей нужны соответствующие настройки клиентов и проверенные права. Для изоляции нескольких арендаторов, удалённого доступа, проектирования ACL и TLS требуется отдельный проект развёртывания.
Шаг 3. Выберите память кэша и параметры сохранения данных
Задайте конечное значение maxmemory, соответствующее вашим реальным мощностям и нагрузке. Например, следующее — только иллюстрация конфигурации, а не рекомендация по размеру:
maxmemory 256mb
maxmemory-policy allkeys-lru
Используйте эту политику вытеснения только для воссоздаваемых данных кэша. maxmemory — не жёсткий предел общей памяти процесса Redis: накладные расходы аллокатора, некоторые буферы и операции сохранения могут потребовать дополнительного запаса. Измеряйте резидентную память Redis и общую нагрузку на хост вместе с использованием приложения.
Решите вопрос сохранения данных отдельно. Одноразовому кэшу дисковое сохранение может не понадобиться, если приложение допускает холодный перезапуск. Если вы осознанно выбираете отсутствие сохранения для нового экземпляра, предназначенного только для кэша, нужные параметры таковы:
save ""
appendonly no
Не применяйте эти настройки к экземпляру, где хранятся данные, которые нужно сохранить. Сохранение может сократить работу по прогреву кэша, но у снимков RDB и AOF разные компромиссы. Включение AOF — не абсолютная гарантия долговечности, а файлы сохранения не заменяют внешние резервные копии и проверенное восстановление.
Примените проверенную конфигурацию в подходящее окно обслуживания:
sudo systemctl restart redis-server
systemctl is-active redis-server
sudo ss -lntp '( sport = :6379 )'
Убедитесь, что слушатель — 127.0.0.1:6379, без публичных слушателей и слушателей на всех интерфейсах. Если сервис не запускается или слушатель неожиданный, остановитесь и изучите sudo journalctl -u redis-server -n 50 --no-pager. Относитесь к логам как к потенциально чувствительным данным. Не устраняйте проблему с локальным подключением, открывая публичный порт.
Шаг 4. Выполните небольшую функциональную проверку
На тестовом экземпляре откройте локальную сессию CLI. Если аутентификация включена, используйте запрос пароля:
redis-cli -h 127.0.0.1 -p 6379 --askpass
Для локального тестового экземпляра без настроенной аутентификации опустите --askpass. Внутри CLI используйте неиспользуемый демонстрационный ключ:
PING
SET sharpheberg:demo:cli hello EX 60
GET sharpheberg:demo:cli
TTL sharpheberg:demo:cli
DEL sharpheberg:demo:cli
EXIT
Ожидаемое поведение (а не записанный вывод тестов): PONG для PING, OK для SET и hello для GET до истечения срока. TTL должен быть положительным, если проверить его сразу; -2 означает, что ключа больше нет, а -1 — что у него нет срока действия. DEL возвращает 1, если ключ ещё существовал, или 0, если срок уже истёк. Это подтверждает базовый доступ к командам, а не более быструю загрузку страниц или производительность хостинга.
Шаг 5. Подключите приложение
WordPress: постоянный объектный кэш, а не кэш полных страниц
Плагин Redis Object Cache предоставляет постоянный бэкенд для API объектного кэша WordPress. «Постоянный» здесь означает, что кэшированные объекты можно использовать повторно между PHP-запросами; это не значит, что включено дисковое сохранение Redis. Плагин не кэширует автоматически все SQL-запросы и не создаёт кэш полных HTML-страниц.
- Сделайте резервную копию конфигурации WordPress и проверьте, не установлен ли уже drop-in объектного кэша.
- Сначала установите и активируйте Redis Object Cache на staging-сайте.
- Передайте пароль Redis через механизм управления секретами вашей среды выполнения PHP. В примере ниже переменная окружения называется
REDIS_PASSWORD; WordPress получает её через константуWP_REDIS_PASSWORD. - Добавьте следующее в фактический
wp-config.phpвашего сайта, до того как WordPress загрузитwp-settings.php. Используйте префикс, уникальный для этого сайта.
$redisPassword = getenv('REDIS_PASSWORD');
if ($redisPassword === false || $redisPassword === '') {
throw new RuntimeException('Redis secret is not available to PHP.');
}
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'example-site:');
define('WP_REDIS_PASSWORD', $redisPassword);
unset($redisPassword);
Этот пример с аутентификацией намеренно выдаёт чёткую ошибку при отсутствии секрета; сначала настройте среду выполнения и проверьте всё на staging, чтобы не нарушить работу рабочего сайта. Одного экспорта в оболочке обычно недостаточно, чтобы переменная стала доступна PHP-FPM или Apache. Явно передайте её нужному пулу PHP-воркеров или сервису с помощью защищённой конфигурации или интеграции секретов, затем перезагрузите эту среду выполнения, если это необходимо. Убедитесь, что WP-CLI получает тот же секрет при его использовании. Не раскрывайте значения окружения на публичных страницах отладки или в логах.
Если ваш изолированный экземпляр Redis намеренно не использует аутентификацию, опустите и блок загрузки пароля, и WP_REDIS_PASSWORD; не подставляйте пустой секрет в пример с аутентификацией. Для пользователя ACL следуйте описанному в документации плагина формату имени пользователя и пароля.
Откройте Настройки → Redis, включите объектный кэш и проверьте, что отображается статус подключения и активный drop-in. Изучите параметры конфигурации и инструкции по установке от разработчиков для вашей установленной версии. Уникальный префикс и выбранная база данных помогают избежать коллизий; они не являются границами безопасности, а поведение сброса кэша необходимо изучить, прежде чем использовать один экземпляр для нескольких сайтов.
Проверьте поведение для авторизованных и неавторизованных пользователей, инвалидацию кэша и реакцию приложения, когда Redis недоступен. Кэширование полных страниц — отдельный уровень со своими требованиями к совместимости и инвалидации.
Node.js: автономный пример на node-redis v5
Используйте поддерживаемый релиз Node.js, совместимый с пакетом. В вашем приложении или отдельной демонстрационной директории установите основную версию v5 и запишите установленную версию:
npm install redis@5
npm ls redis
Сохраните сгенерированный lock-файл для воспроизводимости. Сохраните следующий код как node-example.cjs. Он ожидает реального подключения, использует истекающий ключ, уникальный для этого запуска, проверяет его значение и TTL и удаляет только этот демонстрационный ключ. Он не зависит от воображаемой базы данных.
'use strict';
const { createClient } = require('redis');
const { randomUUID } = require('node:crypto');
const assert = require('node:assert/strict');
async function main() {
const client = createClient({
url: process.env.REDIS_URL || 'redis://127.0.0.1:6379',
socket: { connectTimeout: 5000, reconnectStrategy: false }
});
client.on('error', () => console.error('Redis client error; check service and connection settings.'));
const key = `sharpheberg:demo:node:${randomUUID()}`;
try {
await client.connect();
assert.equal(await client.set(key, 'hello', { EX: 60 }), 'OK');
const value = await client.get(key);
assert.equal(value, 'hello');
const ttl = await client.ttl(key);
assert.ok(ttl > 0 && ttl <= 60, 'Demo key must have a positive TTL');
console.log('GET:', value);
console.log('TTL (seconds):', ttl);
assert.equal(await client.del(key), 1);
assert.equal(await client.get(key), null);
console.log('Demo key deleted.');
} finally {
if (client.isReady) {
try {
await client.del(key);
await client.close();
} finally {
if (client.isOpen) client.destroy();
}
} else if (client.isOpen) {
client.destroy();
}
}
}
main().catch(() => {
console.error('Redis demo failed; no credentials are printed.');
process.exitCode = 1;
});
Запустите node node-example.cjs. URL по умолчанию — redis://127.0.0.1:6379. Для экземпляра с аутентификацией передайте REDIS_URL через вашу среду выполнения или менеджер секретов; формат поддерживает имя пользователя и пароль, зарезервированные символы в которых необходимо кодировать как URL. Не вводите URL с учётными данными в историю оболочки, не коммитьте и не выводите его. В этом руководстве адрес назначения остаётся локальным.
Руководство по миграции node-redis v5 описывает close() как замену quit(), а destroy() — как метод немедленного разрыва соединения. Здесь клиент закрывается после выполнения awaited-команд и уничтожается, если очистка не может завершиться штатно. Автоматическое переподключение отключено для этой короткой проверки, чтобы недоступный сервер не приводил к бесконечным попыткам подключения. Для production-приложений нужны собственные политики повторных попыток, таймаутов, запасных вариантов при недоступности кэша и завершения работы. Документация по использованию клиента описывает URL подключения и события ошибок.
Область функциональной проверки: цикл PING/SET/GET/TTL/DEL и пример на Node.js были проверены с Redis 8.0.2 на Debian 13 и node-redis 5.12.1 во временном процессе, доступном только через loopback. Пакеты были распакованы в тестовую директорию, а не установлены как сервис хоста. Эти проверки не подтверждают работу на каждом релизе дистрибутива, установку через systemd, интеграцию с WordPress или производительность в production.
Шаг 6. Отслеживайте кэш без нагрузочного теста
В локальной сессии CLI с аутентификацией изучите следующие разделы:
INFO stats
INFO memory
INFO clients
Полезные поля: keyspace_hits, keyspace_misses, evicted_keys, expired_keys, used_memory_human, used_memory_rss и connected_clients. Универсального поля hit_rate, которое можно получить из INFO, не существует.
Для определённого интервала наблюдения запишите изменения числа попаданий и промахов. Только если их сумма положительна, вычислите delta_hits / (delta_hits + delta_misses) × 100. Отбрасывайте интервалы, в которые попадает сброс счётчиков или перезапуск. Это показатель поиска ключей по всему экземпляру, а не доля попаданий в кэш страниц и не прямая мера сокращения SQL-запросов.
Измеряйте время ответа приложения, нагрузку на базу данных, ошибки и использование ресурсов до и после интеграции при сопоставимом трафике. Различайте холодный и прогретый кэш и документируйте версии и условия. Синтетический тест пропускной способности SET/GET не может определить скорость страниц WordPress, а ни успешный PING, ни эта демонстрация не подтверждают никакого SLA хостинга.
Устранение неполадок и дополнительная тонкая настройка
- Connection refused: проверьте статус сервиса, логи, фактический адрес и порт привязки и не находится ли приложение в контейнере. Сохраняйте конфигурацию только с loopback; не добавляйте публичное исключение в firewall.
- Ошибка аутентификации: убедитесь, что приложение получает нужный секрет и использует правильного пользователя Redis. Не раскрывайте пароли при отладке.
- Отсутствующие ключи в кэше: проверьте TTL, инвалидацию, счётчики вытеснения, префиксы и выбор базы данных. Промахи кэша должны быть безопасными для воссоздаваемых данных.
- Нехватка памяти: изучите резидентную память Redis, память хоста, вытеснение и поведение приложения. Пересмотрите расчёт размера, а не считайте больший
maxmemoryавтоматическим решением. - Медленные операции: избегайте широких сканирований ключей и крупных блокирующих операций на загруженном экземпляре. Если нужен перебор, используйте инкрементальный SCAN, а для крупных удалений рассмотрите UNLINK. Никогда не сбрасывайте общие данные как способ устранения неполадок.
Тонкая настройка ядра не является обязательным шагом установки. Руководство Redis по задержкам рекомендует отключить Transparent Huge Pages (THP). Если это актуально для вашей измеренной нагрузки, согласуйте это с администратором хоста или ОС, используйте поддерживаемый дистрибутивом постоянный способ и запланируйте перезапуск Redis. Временная запись в /sys не сохраняется после перезагрузки. Изучайте overcommit и другие изменения sysctl отдельно; не копируйте универсальные значения backlog и сетевых буферов на общий VPS.
Исследуйте лимиты файловых дескрипторов, только если наблюдаемый спрос на подключения или ошибки это оправдывают:
systemctl show redis-server -p LimitNOFILE
Для Redis под управлением systemd при необходимости используйте проверенное переопределение [Service] с измеренным значением LimitNOFILE=, затем перезагрузите systemd и запланируйте контролируемый перезапуск. Изменения ulimit оболочки или лимитов PAM для этого сервиса недостаточно. Настройки сервиса объясняет документация systemd по лимитам ресурсов.
Планируйте развёртывание Redis на VPS
Полезное развёртывание Redis начинается с чёткой семантики кэша, доступа только с локальной машины, осознанного выбора памяти и параметров сохранения данных и проверок на уровне приложения. Храните основные данные отдельно от одноразовых данных кэша и проверяйте выгоду на собственной нагрузке, прежде чем масштабироваться.
Сравните ресурсы и возможности, указанные сейчас в тарифах Linux VPS от SharpHeberg, и выберите среду для вашего приложения и локального кэша Redis. Рассчитывайте размер под весь стек, оставляйте запас мощности и проверяйте конфигурацию на выбранной операционной системе перед развёртыванием в production.