redis java что это
Знакомимся с Redis
Узнаём, для чего эта СУБД нужна и как ею пользоваться.
pierre borthiry / unsplash
Redis ( REmote DIctionary Server, «удалённый серверный словарь») — это нереляционная резидентная СУБД, хранящая данные в виде пар «ключ-значение».
От реляционных баз Redis отличается:
Разрабатывает приложения на Java, воспитывает двух котов: Котлин и Монго.
Для чего используют Redis
Redis обычно применяют:
Как начать работать с Redis
Самый лёгкий способ — запустить Redis в docker-контейнере (если не знаете, что это, — добро пожаловать сюда).
Запускаем контейнер командой:
Убедимся, что контейнер запущен:
Затем открываем новую сессию и интерфейс командной строки ( CLI ):
Можно и сразу перейти в консоль Redis:
Вот мы и готовы работать с Redis.
Основные команды
Рассмотрим основные операции на примере хеш-таблиц.
HSET — сохраняет значение по ключу:
В примере выше мы создали объект person1 с двумя полями ( name и age) и соответствующими значениями.
HGET — получение значения по ключу (для определённого поля):
Выше мы получили значение поля name у ключа person1.
HGETALL — получение всех пар «ключ-значение»:
Получили значения всех полей по ключу person1.
HKEYS и HVALS — получение всех ключей и соответствующих им значений:
Как работать с оставшимися структурами данных — смотрите в официальном руководстве.
Транзакции
Важно понимать, что транзакции в Redis не сохраняют целостность данных (сбой одной операции при выполнении блока транзакции не мешает исполнить другие).
После запуска команды multi интерфейс redis-cli ответил на каждую последующую состоянием QUEUED («в очереди»). Когда мы запустили команду exec, то получили выходные данные каждой команды из очереди.
Отменить транзакцию можно командой discard. Она предотвратит запуск всех команд, ранее поставленных в очередь, — и Redis снова будет выполнять команды в обычном режиме. Чтобы сообщить серверу, что вы открываете новую транзакцию, нужно снова запустить multi.
Важно понимать, что когда команда уже встала в очередь (то есть синтаксически верна), то, даже если она и вызовет ошибку при выполнении, остальные команды выполнятся всё равно. А вот если не встала (невалидна, вызвала ошибку при постановке в очередь), то Redis блок транзакции отклонит, даже не дождавшись exec. И если вы попытаетесь после этого выполнить exec, вам скажут, что транзакция была отклонена из-за предыдущих ошибок.
Как Redis обрабатывает ошибки внутри транзакций, читайте тут.
Механизм подписок
Он позволяет одному клиенту создать канал событий и публиковать туда сообщения, а другому — подписываться и читать эти сообщения (так можно создать простой чат).
Механизм подписок не гарантирует, что сообщение будет доставлено. Мы отправляем сообщение в канал, а кто его примет (и примет ли) — обещать не можем, стоит помнить об этом и не использовать подписки там, где важно обратное.
Итак, клиент подписывается на канал командой:
Redis на практических примерах
Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.
Рассмотрим следующие кейсы:
Кэширование данных
Давайте начнем с самого простого, один из самых популярных кейсов использования Redis — кэширование данных. Будет полезно для тех, кто не работал с Redis. Для тех, кто уже давно пользуется этим инструментом — можно смело переходить к следующему кейсу. Для того, чтобы снизить нагрузку на БД, иметь возможность запрашивать часто используемые данные максимально быстро, используется кэш. Redis — это in-memory хранилище, то есть данные хранятся в оперативной памяти. Ещё это key-value хранилище, где доступ к данным по их ключу имеет сложность O(1) — поэтому данные мы получаем очень быстро.
Получение данных из хранилища выглядит следующим образом:
Но для того, чтобы данные из кэша получить, их нужно сначала туда положить. Простой пример записи:
Таким образом, мы запишем данные в Redis и сможем их считать по тому же самому ключу в любой нужный нам момент. Но если мы будем все время писать в Redis, данные в нем будут занимать все больше и больше места в оперативной памяти. Нам нужно удалять нерелевантные данные, контролировать это вручную достаточно проблематично, поэтому пускай redis занимается этим самостоятельно. Добавим к нашему ключу TTL (время жизни ключа):
По истечении времени ttl (в секундах) данные по этому ключу будут автоматически удалены.
Как говорят, в программировании существует две самых сложных вещи: придумывание названий переменных и инвалидация кэша. Для того, чтобы принудительно удалить значение из Redis по ключу, достаточно выполнить следующую команду:
Также редис позволяет получить массив значений по списку ключей:
И соответственно массовое удаление данных по массиву ключей:
Очереди
Используя имеющиеся в Redis структуры данных, мы можем запросто реализовать стандартные очереди FIFO или LIFO. Для этого используем структуру List и методы по работе с ней. Работа с очередями состоит из двух основных действий: отправить задачу в очередь, и взять задачу из очереди. Отправлять задачи в очередь мы можем из любой части системы. Получением задачи из очереди и ее обработкой обычно занимается выделенный процесс, который называется консьюмером (consumer).
Итак, для того, чтобы отправить нашу задачу в очередь, нам достаточно использовать следующий метод:
Со стороны консьюмера нам необходимо обеспечить получение задач из очереди, это реализуется простой командой чтения из листа. Для реализации FIFO очереди мы используем чтение с обратной записи стороны (в нашем случае мы писали через RPUSH), то есть читать будем через LPOP:
Для реализации LIFO очереди, нам нужно будет читать лист с той же стороны, с которой мы в него пишем, то есть через RPOP.
Тем самым мы вычитываем по одному сообщению из очереди. В случае если листа не существует (он пустой), то мы получим NULL. Каркас консьюмера мог бы выглядеть так:
Для того, чтобы получить информацию о глубине очереди (сколько значений хранится в нашем листе), можем воспользоваться следующей командой:
Мы рассмотрели базовую реализацию простых очередей, но Redis позволяет строить более сложные очереди. Например, мы хотим знать о времени последней активности наших пользователей на сайте. Нам не важно знать это с точностью вплоть до секунды, приемлемая погрешность — 3 минуты. Мы можем обновлять поле last_visit пользователя при каждом запросе на наш бэкенд от этого пользователя. Но если этих пользователей большое количество в онлайне — 10,000 или 100,000? А если у нас еще и SPA, которое отправляет много асинхронных запросов? Если на каждый такой запрос обновлять поле в бд, мы получим большое количество тупых запросов к нашей БД. Эту задачу можно решать разными способами, один из вариантов — это сделать некую отложенную очередь, в рамках которой мы будем схлопывать одинаковые задачи в одну в определенном промежутке времени. Здесь на помощь нам придет такая структура, как Sorted SET. Это взвешенное множество, каждый элемент которого имеет свой вес (score). А что если в качестве score мы будем использовать timestamp добавления элемента в этот sorted set? Тогда мы сможем организовать очередь, в которой можно будет откладывать некоторые события на определенное время. Для этого используем следующую функцию:
Теперь возникает вопрос о том, как читать эту очередь. Если методы LPOP и RPOP для листа читают значение и удаляют его из листа атомарно (это значит, что одно и тоже значение не может быть взято несколькими консьюмерами), то sorted set такого метода из коробки не имеет. Мы можем сделать чтение и удаление элемента только двумя последовательными командами. Но мы можем выполнить эти команды атомарно, используя простой LUA скрипт!
В этом LUA скрипте мы пытаемся получить первое значение с весом в диапазоне от 0 до текущего timestamp в переменную val с помощью команды ZRANGEBYSCORE, если нам удалось получить это значение, то удаляем его из sorted set командой ZREM и возвращаем само значение val. Все эти операции выполняются атомарно. Таким образом мы можем вычитывать нашу очередь в консьюмере, аналогично с примером очереди построенной на структуре LIST.
Я рассказал про несколько базовых паттернов очередей, реализованных в нашей системе. На текущий момент у нас в продакшене существуют более сложные механизмы построения очередей — линейных, составных, шардированных. При этом Redis позволяет все это делать при помощи смекалки и готовых круто работающих структур из коробки, без сложного программирования.
Блокировки (Mutex)
Mutex (блокировка) — это механизм синхронизации доступа к shared ресурсу нескольких процессов, тем самым гарантируя, что только один процесс будет взаимодействовать с этим ресурсом в единицу времени. Этот механизм часто применяется в биллинге и других системах, где важно соблюдать потоковую безопасность (thread safety).
Для реализации mutex на базе Redis прекрасно подойдет стандартный метод SET с дополнительными параметрами:
где параметрами для установки mutex являются:
Чаще всего, когда мы пишем код, который пытается работать с shared ресурсом, который заблокирован, мы хотим дождаться его разблокировки и продолжить работу с этим ресурсом. Для этого можем реализовать простой метод для ожидания освободившегося ресурса:
Мы разобрались как ставить блокировку, теперь нам нужно научиться ее снимать. Для того, чтобы гарантировать снятие блокировки тем процессом, который ее установил, нам понадобится перед удалением значения из хранилища Redis, сверить хранимый хэш по этому ключу. Для того, чтобы сделать это атомарно, воспользуемся LUA скриптом:
Rate limiter
Достаточно частая задача, когда мы хотим ограничить количество запросов к нашему апи. Например на один API endpoint от одного аккаунта мы хотим принимать не более 100 запросов в минуту. Эта задача легко решается с помощью нашего любимого Redis:
Таким простым методом мы можем лимитировать количество запросов к нашему API, базовый каркас нашего контроллера мог бы выглядеть следующим образом:
Pub/sub
Pub/sub — интересный механизм, который позволяет, с одной стороны, подписаться на канал и получать сообщения из него, с другой стороны — отправлять в этот канал сообщение, которое будет получено всеми подписчиками. Наверное у многих, кто работал с вебсокетами, возникла аналогия с этим механизмом, они действительно очень похожи. Механизм pub/sub не гарантирует доставки сообщений, он не гарантирует консистентности, поэтому не стоит его использовать в системах, для которых важны эти критерии. Однако рассмотрим этот механизм на практическом примере. Предположим, что у нас есть большое количество демонизированных команд, которыми мы хотим централизованно управлять. При инициализации нашей команды мы подписываемся на канал, через который будем получать сообщения с инструкциями. С другой стороны у нас есть управляющий скрипт, который отправляет сообщения с инструкциям в указанный канал. К сожалению, стандартный PHP работает в одном блокирующем потоке; для того, чтобы реализовать задуманное, используем ReactPHP и реализованный под него клиент Redis.
Отправка сообщения в канал — более простое действие, мы можем сделать это абсолютно из любого места системы одной командой:
В результате такой отправки сообщения в канал, все клиенты, которые подписаны на данный канал, получат это сообщение.
Введение в Jedis – клиентская библиотека Java Redis
Введение в Jedis, клиентскую библиотеку на Java для Redis – популярного хранилища структур данных в памяти, которое также может сохраняться на диске.
1. Обзор
Во-первых, мы собираемся объяснить, в каких ситуациях джедаи полезны и о чем идет речь.
В последующих разделах мы подробно рассмотрим различные структуры данных и объясним транзакции, конвейерную обработку и функцию публикации/подписки. Мы завершаем работу с пулом соединений и кластером Redis.
2. Почему джедаи?
У этих двух клиентов есть некоторые уникальные функции, такие как потокобезопасность, прозрачная обработка повторного подключения и асинхронный API, всех функций которого не хватает Jedis.
Однако он невелик и значительно быстрее, чем два других. Кроме того, это клиентская библиотека по выбору разработчиков Spring Framework, и у нее самое большое сообщество из всех трех.
3. Зависимости Maven
Давайте начнем с объявления единственной зависимости, которая нам понадобится в pom.xml :
4. Установка Redis
Вам нужно будет установить и запустить одну из последних версий Redis. На данный момент мы запускаем последнюю стабильную версию (3.2.1), но любая версия post 3.x должна быть в порядке.
Найдите здесь дополнительную информацию о Redis для Linux и Macintosh, у них очень похожие основные шаги установки. Windows официально не поддерживается, но этот порт хорошо поддерживается.
После этого мы можем напрямую погрузиться в него и подключиться к нему из нашего Java-кода:
Конструктор по умолчанию будет работать нормально, если вы не запустили службу на порту, отличном от порта по умолчанию, или на удаленной машине, и в этом случае вы можете правильно настроить ее, передав правильные значения в качестве параметров в конструктор.
5. Структуры Данных Redis
Большинство собственных команд операций поддерживаются, и, что достаточно удобно, они обычно имеют одно и то же имя метода.
5.1. Строки
Строки-это самый простой вид Redisvalue, полезный для тех случаев, когда вам нужно сохранить простые типы данных ключ-значение:
5.2. Списки
Списки Redis-это просто списки строк, отсортированных по порядку вставки, что делает его идеальным инструментом для реализации, например, очередей сообщений:
5.3. Наборы
Наборы Redis-это неупорядоченная коллекция строк, которая пригодится, если вы хотите исключить повторяющиеся элементы:
5.4. Хэши
Хэши Redis сопоставляются между полями String и значениями String :
Как вы можете видеть, хэши-это очень удобный тип данных, когда вы хотите получить доступ к свойствам объекта по отдельности, поскольку вам не нужно извлекать весь объект целиком.
5.5. Сортированные наборы
Сортированные наборы подобны набору, в котором каждый член имеет связанный рейтинг, который используется для их сортировки:
Переменная player будет содержать значение PlayerThree потому что мы извлекаем первого игрока, и он тот, у кого самый высокий балл. Переменная rank будет иметь значение 1, потому что Игрок Один является вторым в рейтинге, а рейтинг основан на нуле.
6. Сделки
Транзакции гарантируют атомарность и потокобезопасность операций, что означает, что запросы от других клиентов никогда не будут обрабатываться одновременно во время транзакций Redis:
Вы даже можете сделать успех транзакции зависящим от определенного ключа, “наблюдая” за ним прямо перед созданием экземпляра вашей Транзакции :
Если значение этого ключа изменится до выполнения транзакции, транзакция не будет успешно завершена.
7. Конвейеризация
Когда нам нужно отправить несколько команд, мы можем упаковать их вместе в один запрос и сэкономить накладные расходы на соединение с помощью конвейеров, по сути, это оптимизация сети. До тех пор, пока операции взаимно независимы, мы можем воспользоваться этой техникой:
8. Публикация/Подписка
Мы можем использовать функцию брокера обмена сообщениями Redis для отправки сообщений между различными компонентами нашей системы. Убедитесь, что потоки подписчика и издателя не используют одно и то же соединение Jedis.
8.1. Подписчик
Подписывайтесь и слушайте сообщения, отправленные на канал:
8.2. Издатель
Затем просто отправляйте сообщения на тот же канал из потока издателя:
9. Объединение Пулов Соединений
Важно знать, что то, как мы обращаемся с нашим примером джедаев, наивно. В реальном сценарии вы не хотите использовать один экземпляр в многопоточной среде, поскольку один экземпляр не является потокобезопасным.
К счастью, мы можем легко создать пул подключений к Redis для повторного использования по требованию, пул, который является потокобезопасным и надежным, если вы вернете ресурс в пул, когда закончите с ним.
Давайте создадим JedisPool :
Поскольку экземпляр пула является потокобезопасным, вы можете хранить его где-то статически, но вы должны позаботиться об уничтожении пула, чтобы избежать утечек при завершении работы приложения.
Теперь мы можем использовать наш пул из любой точки приложения, когда это необходимо:
Убедитесь, что вы используете пул, как мы описали в вашем приложении, если вы не хотите столкнуться с неприятными проблемами многопоточности. Очевидно, вы можете играть с параметрами конфигурации пула, чтобы адаптировать его к лучшим настройкам в вашей системе.
10. Кластер Redis
Как только мы будем готовы, мы сможем начать использовать его из нашего приложения:
Нам нужно только предоставить сведения о хосте и порте из одного из наших главных экземпляров, он автоматически обнаружит остальные экземпляры в кластере.
Это, безусловно, очень мощная функция, но это не серебряная пуля. При использовании кластера Redis вы не можете выполнять транзакции или использовать конвейеры-две важные функции, на которые полагаются многие приложения для обеспечения целостности данных.
Транзакции отключены, поскольку в кластеризованной среде ключи будут сохраняться в нескольких экземплярах. Атомарность операций и безопасность потоков не могут быть гарантированы для операций, связанных с выполнением команд в разных экземплярах.
Некоторые продвинутые стратегии создания ключей гарантируют, что данные, которые вам интересны, будут сохранены в одном и том же экземпляре, будут сохранены таким образом. Теоретически это должно позволить вам успешно выполнять транзакции, используя один из базовых экземпляров Jedis кластера Redis.
11. Заключение
Подавляющее большинство функций Redis уже доступны в Jedis, и его развитие продвигается хорошими темпами.
Это дает вам возможность интегрировать мощный механизм хранения данных в памяти в ваше приложение без особых проблем, просто не забудьте настроить пул соединений, чтобы избежать проблем с безопасностью потоков.
Redis
Быстрое хранилище данных в памяти с открытым исходным кодом для использования в качестве базы данных, кэша, брокера сообщений или очереди.
Что такое Redis?
Redis (расшифровывается как Remote Dictionary Server) – это быстрое хранилище данных типа «ключ‑значение» в памяти с открытым исходным кодом. Проект возник, когда Сальваторе Санфилиппо, первоначальный разработчик Redis, захотел улучшить масштабируемость стартапа в Италии. Он создал хранилище Redis, которое теперь используется в качестве базы данных, кэша, брокера сообщений и очереди.
Redis обеспечивает время отклика на уровне долей миллисекунды и позволяет приложениям, работающим в режиме реального времени, выполнять миллионы запросов в секунду. Такие приложения востребованы в сферах игр, рекламных технологий, финансовых сервисов, здравоохранения и IoT. Сегодня Redis – одно из наиболее популярных ядер с открытым исходным кодом, в течение пяти лет подряд называемое «самой любимой» базой данных от Stack Overflow. Благодаря быстрой производительности Redis широко применяется для кэширования, управления сеансами, разработки игр, создания таблиц лидеров, аналитики в режиме реального времени, работы с геопространственными данными, поддержки служб такси, чатов и сервисов обмена сообщениями, потоковой передачи мультимедиа и приложений с отправкой сообщений по модели «издатель – подписчик» (Pub/Sub).
AWS предлагает два полностью управляемых сервиса для запуска Redis. Amazon MemoryDB for Redis – совместимый с Redis надежный сервис базы данных в памяти, который обеспечивает сверхбыструю производительность. Amazon ElastiCache for Redis – полностью управляемый сервис кэширования, который ускоряет доступ к данным из первичных баз данных и хранилищ с микросекундной задержкой. Более того, ElastiCache также предлагает поддержку Memcached, другой популярной системы кэширования с открытым исходным кодом.
Подробную информацию об ускорении приложений с Amazon ElastiCache for Redis см. в онлайн-вебинаре Tech Talk.
Преимущества Redis
Производительность
Все данные Redis хранятся в памяти, что обеспечивает низкую задержку и высокую пропускную способность доступа к данным. В отличие от традиционных баз данных, хранилища данных в памяти не требуют перемещения на диск, что сокращает задержку ядра до микросекунд. Благодаря этому хранилища данных в памяти могут многократно увеличивать количество выполняемых операций и сокращать время отклика. В результате обеспечивается чрезвычайно высокая производительность. Операции чтения и записи в среднем занимают менее миллисекунды, скорость работы достигает миллионов операций в секунду.
Гибкие структуры данных
В отличие от других хранилищ на основе пар «ключ – значение», которые поддерживают ограниченный набор структур данных, Redis поддерживает огромное разнообразие структур данных, позволяющее удовлетворить потребности разнообразных приложений. Типы данных Redis включают:
Простота и удобство
Redis позволяет писать такой же сложный код с меньшим количеством простых строк. Redis позволяет писать меньше строк для хранения, использования данных и организации доступа к данным в приложениях. Разница в том, что, в отличие от языков запросов традиционных баз данных, с Redis разработчики могут использовать простую структуру команд. Например, вы можете задействовать структуру хэш-данных Redis, чтобы перемещать данные в хранилище только одной строкой кода. Решение подобной задачи с использованием хранилища данных, не поддерживающего структуры хэш‑таблиц, потребует написания серьезного объема кода для преобразования данных из одного формата в другой. Redis уже оснащен встроенными структурами данных и предоставляет множество возможностей их комбинирования и взаимодействия с данными клиента. Разработчикам под Redis доступны более ста клиентов с открытым исходным кодом. Поддерживаемые языки программирования включают Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, R, Go и многие другие.
Репликация и постоянное хранение
В Redis применяется архитектура узлов «ведущий‑подчиненный» и поддерживается асинхронная репликация, при которой данные могут копироваться на несколько подчиненных серверов. Это обеспечивает как улучшенные характеристики чтения (так как запросы могут быть распределены между серверами), так и ускоренное восстановление в случае сбоя основного сервера. Для обеспечения постоянного хранения Redis поддерживает снимки состояния на момент времени (копирование наборов данных Redis на диск).
Высокая доступность и масштабируемость
Redis предлагает архитектуру «ведущий‑подчиненный» с одним ведущим узлом или с кластерной топологией. Это позволяет создавать высокодоступные решения, обеспечивающие стабильную производительность и надежность. Если требуется настроить размер кластера, доступны различные варианты вертикального и горизонтального масштабирования. В результате можно наращивать кластер в соответствии с потребностями.
Инструменты с открытым исходным кодом
Redis – проект с открытым исходным кодом, поддерживаемый активным сообществом, включая AWS. Поскольку Redis базируется на открытых стандартах, поддерживает открытые форматы данных и имеет множество клиентов, отсутствует вероятность блокировки поставщиком или технологического тупика.