С вас вопросы, с нас ответы. Часть 17

Вообще Redis — это система управления базами данных. Но зачастую воспринимается как просто хранилище данных, использующее key-value подход.

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

Дополнительно к этому Redis использует эффективные внутренние структуры данных и в основном последовательно выполняет короткие команды, используя механизм event loop, что упрощает обработку запросов даже с использованием одного потока.

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

Этот инструмент особенно полезен там, где данные нужно читать или изменять очень часто с минимальной задержкой.

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

Наверное, Redis правильнее понимать именно как быстрое хранилище структур данных.

Основными структурами данных, конечно, являются string, hash, list, set, sorted set и stream:

• строки (string) подходят для хранения строковых данных и числовых счётчиков;
• хеши (hash) — для объектов с набором полей;
• set нужен для хранения уникальных значений,
• а sorted set — для рейтингов и упорядоченных выборок.
• и, конечно, stream хранит и помогает обрабатывать потоки событий.

Но это лишь базовые структуры данных. Redis поддерживает более сложные и продвинутые возможности, например JSON, временные ряды и векторный поиск, который помогает реализовывать AI-решения.

Зачастую это не взаимоисключающий выбор. Как минимум потому, что PostgreSQL относится к семейству реляционных баз данных, а Redis — к NoSQL-хранилищам, которые в целом могут решать разные классы задач.

PostgreSQL подходит на роль основного долговечного хранилища со сложными запросами, связями и транзакциями. Однако с этими вещами у Redis есть ограничения. Например, в нём есть собственный механизм транзакций через MULTI/EXEC, но он отличается от классических транзакций реляционных баз данных и не предоставляет привычного механизма отката изменений.

Тем не менее, Redis отлично работает там, где нужен быстрый доступ к данным, очереди, кэширование части необходимой для ответа информации. И именно поэтому в реальных проектах PostgreSQL и Redis работают вместе.

Один из самых распространённых подходов — это cache-aside: приложение сначала проверяет Redis на наличие необходимой информации, и при промахе читает данные из основной базы и сохраняет результат в кэш.

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

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

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

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

Pub/Sub — это простой механизм доставки сообщений подписчикам в реальном времени. При этом сообщение в Redis не хранится. Если потребитель отключился, то он никогда не увидит отправленные во время его даунтайма сообщения. Перечитать их нельзя.

Streams, наоборот, хранят сообщения и являются журналом этих сообщений, позволяя поддерживать группы потребителей. Streams позволяют, в отличие от Pub/Sub, организовать повторную обработку сообщения, поэтому подходят для более надёжной асинхронной обработки событий.

Redis Sentinel решает прежде всего задачу высокой доступности обычной схемы master-replica: следит за узлами и при отказе master может автоматически повысить одну из реплик до нового master, опросив при этом все узлы и достигнув кворума принятия решения. Redis Cluster решает ещё и задачу горизонтального масштабирования: пространство ключей делится на 16 384 слота, которые распределяются между несколькими master-узлами, а реплики используются для отказоустойчивости.

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

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

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