Redis появляется в проекте, чтобы снять нагрузку с PostgreSQL. Через полгода в нём уже лежат сессии, счётчики rate limit, фоновые задачи и флаги функциональности. Через год Redis перезапускается после сбоя. Оказывается, что пропал не ускоритель: исчезли незавершённые заказы, обнулились лимиты API, пропала часть задач.
Проблема не в Redis. Команда продолжает называть кэшем слой, который давно стал базой данных.
Спор «Redis или PostgreSQL» обычно ведут не о том. Скорость и технология вторичны. Главный вопрос: что случится, если этот слой исчезнет прямо сейчас?
Если данные можно пересчитать из другого источника, это кэш. Его потеря увеличит задержки и нагрузку на основную БД, но бизнес-состояние останется целым.
Если другой копии нет, это база данных, даже если она живёт в RAM, имеет TTL и в конфиге называется cache. Сюда относятся запись о платеже, единственное описание фоновой задачи, счётчик, без которого клиент обходит платный лимит. Потеря таких данных — уже инцидент, а не деградация.
Отсюда практическое правило: сначала определить семантику данных, потом выбирать инструмент.
Cache-aside — самый популярный вариант. Приложение ищет ключ в кэше, при промахе идёт в БД и кладёт результат обратно. Это экономно, но при холодном старте тысячи запросов одновременно бьют в базу. Вторая беда — устаревшие данные: забыли удалить ключ после обновления, и кэш отдаёт старое состояние. Для ленты новостей это терпимо, для баланса счёта нет.
Write-through пишет синхронно в кэш и в БД. Данные актуальны, но каждая запись дороже, а кэш забивается тем, что никто не читает.
Write-behind подтверждает запись сразу, а в БД сбрасывает асинхронно. Для счётчиков и телеметрии это удобно. Для заказов и платежей такой подход допустим только при одном условии: промежуточный слой сам поддерживает журнал, репликацию и восстановление. Иначе сбой до сброса означает потерю уже подтверждённых операций.
Инвалидация остаётся главной головной болью. TTL прост, но держит устаревшее значение до конца срока. CDC точнее, но если поток событий отстал, кэш тихо расходится с источником. Версионные ключи снижают гонки, зато усложняют схему и контроль памяти. Закономерность простая: чем чаще обновляются данные и чем дороже устаревшее чтение, тем меньше пользы от отдельного кэша.
У Redis есть персистентность, но её нужно настраивать осознанно. RDB делает снимки по расписанию: всё, что изменилось после последнего снимка, при аварии теряется. AOF с fsync раз в секунду, по документации Redis, может потерять около секунды записей. Репликация в Redis Cluster асинхронная, поэтому при переключении на реплику последние операции тоже могут пропасть.
Для кэша это нормально. Для сессий, очередей и лимитов нужно честно посчитать RPO и понять, устраивает ли он бизнес. Если Redis стал источником истины, эксплуатировать его надо как БД: с политикой персистентности, мониторингом и учениями по восстановлению.
Есть и третий путь. Связка «приложение → Redis → PostgreSQL» означает двойную запись, инвалидацию и два сценария отказа. Вместо неё можно использовать in-memory СУБД. Такие системы держат горячие данные в памяти, но фиксируют изменения в журнале предзаписи (WAL), делают снимки состояния, поддерживают репликацию и транзакции. По скорости это кэш, по ответственности за данные — база.
К этому классу относится, например, Tarantool. Движок memtx хранит данные в RAM, vinyl — на диске для объёмов больше памяти. Есть WAL, вторичные индексы и SQL. Синхронная репликация нужна там, где транзакция не должна считаться подтверждённой до записи на реплики.
Универсальной заменой PostgreSQL такой подход не станет: тяжёлая аналитика и сложные ad hoc-запросы остаются в реляционных и OLAP-системах. Но для горячего OLTP-контура — сессий, профилей, лимитов, очередей — консолидация убирает целый слой из стека.
Стоит пересмотреть архитектуру, если к вам относятся хотя бы несколько пунктов:
Если же данные полностью производные, устаревшее чтение безопасно, а падение Redis означает только всплеск нагрузки на БД, оставьте классический кэш. Простая архитектура лучше сложной, пока она честно соответствует семантике данных.
Подробный разбор с таблицей сравнения и FAQ — в блоге Tarantool: Кэш и база данных: отличия и граница ответственности.
Без сомнения квадрокоптер WLtoys V686G является не только самым привлекательным в ряду всех своих возможных
Привлечение дополнительного трафика и повышение продаж с помощью интернет ресурса обеспечивается за счет использования
Почти наверняка вам иногда требуется перенести файлы с телефона Android на ПК или Mac. Из-за открытой и прозрачной
