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

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

Но почему тогда Redis может выступать сразу в нескольких ролях?

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

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

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

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

И получается интересная ситуация: один и тот же Redis в проекте может одновременно использоваться для хранения данных, кэширования и обмена сообщениями. Поэтому фраза «у нас используется Redis» сама по себе для QA почти ничего не говорит. Гораздо полезнее выяснить, для чего именно он используется. Это база данных или кэш? Используется Pub/Sub или Streams? Есть ли сохранение данных? Что происходит, если потребитель недоступен? Можно ли повторно обработать сообщение? Используются ли группы потребителей? Что произойдёт с системой, если Redis станет недоступен? И вот здесь знание технологии превращается уже в понимание конкретной системы.

Как думаете, достаточно ли QA знать, что «в проекте есть Redis», или всё-таки нужно понимать, какую именно роль он выполняет?