redis server что это
Знакомимся с 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 это размещаемое в памяти хранилище ключ-значение, обычно используемое для кэшей и подобных механизмов ускорения сетевых приложений. Мы, тем не менее, храним все наши данные в Redis — в нашей главной базе данных.
Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.
Прежде всего, я хотел бы подчеркнуть что большинство приложений вовсе не должны обращать внимания на костыли использованные, что бы пойти таким путём. Это было важно для нашего сценария использования, но мы можем быть граничным случаем.
Redis как хранилище данных
Redis быстр. Когда я говорю быстр, я имею в виду Быстр с заглавной буквы Б. Это по существу memcached с более продуманными типами данных, нежели просто строковые значения. Даже некоторые продвинутые операции такие, как пересечение множеств, выборка диапазонов zset, ослепительно быстры. Есть все поводы использовать Redis для быстроменяющихся активно запрашиваемых данных. Он довольно часто используется в качестве кэша, который может быть перестроен по данным из резервной базы данных. Это мощная замена memcached предоставляющая более продвинутое кэширование для различных видов хранимых вами данных.
Как и в memcached, всё находится в памяти. Redis сохраняется на диск, но он не сохраняет данные синхронно с тем как вы записываете их. Есть две причины из-за которых Redis в качестве главного хранилища — отстой:
— Вы вынуждены умещать все свои данные в памяти, и…
— Если сервер откажет между двумя синхронизациями с диском — вы потеряете всё что сидело в памяти.
Из-за этих двух проблем Redis обосновался в компактной нише в качестве временного кэша для данных которыми вы можете пожертвовать, но не главного хранилища данных. Предоставляя быстрый доступ к часто необходимым данным с возможностью перестроения при необходимости.
Недостаток использования более традиционных хранилищ за Redis заключается в затыке с производительностью этих хранилищ. Вам приходится жертвовать производительностью чтобы убедиться, что данные сохранены на диск. Совершенно нормальная сделка для почти каждого приложения. Вы можете получить великолепную производительность по чтению и «хорошую» производительность по записи. Я должен пояснить, что «хорошая» для меня вполне вероятно может быть безумно быстрая для большинства людей. Достаточно сказать, что «хорошая» производительность по записи должна удволетворить большинство, кроме самых высоко нагруженных приложений.
Я полагаю, что вы можете выполнить запрос на запись в Redis а потом сохраниться при помощи реляционного хранилища, но тогда остаются те же риски падения Redis и потери данных очереди записи.
Что нам нужно?
Moot предлагается как полностью бесплатный продукт. Нам, таким образом, необходимо иметь возможность обрабатывать крупные нагрузки на очень небольшом количестве железа. Если нам нужна куча больших баз данных для форума обслуживающего несколько миллионов пользователей в месяц, то нет никаких способов остаться бесплатным сервисом. Поскольку мы хотим, что бы Moot был и бесплатным и неограниченным, мы вынуждены были оптимизировать до предела.
Мы могли бы просто избежать этого установив какие-нибудь ограничения на бесплатные сервисы и брать деньги за просмотр страниц или постов. Не знаю как вы, но я, в общем, не люблю продукты, которые бесплатны «пока вы не раскрутитесь». Скажем, вы настроили форум, а потом что-то на вашем сайте станет вирусным. Внезапно, вас ошарашат счётом за превышение бесплатного уровня. И вот то, что начиналось как развлечение, из-за внезапной популярности вашего блога о теории заговоров, превращается в ужас грядущего счёта. Вас наказывают за ваш успех. Это то, чего мы хотели бы избежать.
Мы так же могли бы решить монетизироваться размещая рекламу, и позволив себе более высокие эксплуатационные расходы. Это, тем не менее, полностью расходится с нашим базовыми ценностями как бизнеса. По нашему мнению, если кто-то собирается размещать рекламу на вашем сайте, это должны быть вы а не мы. Moot должен предлагаться без условий, ограничений и приписок.
Принимая во внимание всё вышесказанное, необходимо достичь непревзойдённой производительности для постинга и чтения не взирая на инженерные сложности. Это базис для нашей возможности работать. У нас была изначальная цель, чтобы все вызовы API обрабатывались менее чем за 10мс даже под высокой нагрузкой, и даже тогда, когда обрабатываются большие сложные списки или поиски. Redis, очевидно, может обеспечить нам такую производительность, но две большие проблемы никуда не делись: Как, блин, мы сможем использовать Redis, если у нас могут быть сотни гигабайт данных, и что делать с падением сервера?
Что же теперь делать?
Так началось наше исследование способов проектирования с учётом этих ограничений. У нас с самого начала было точное понимание какими будут задачи у Moot, и наших ценностей как компании, поэтому нам повезло иметь возможность обдумать эти особенности до написания первых строчек кода. Я полагаю что эти проблемы были бы чрезмерно сложны, если бы мы решили пойти этим путём, имея множество готового кода.
Все данные в памяти. Блин.
Это самая сложна из двух проблем. Количество памяти, которое может быть на одном компьютере, конечно. Наибольшее количество на EC2 это 244-гигабайтный сервер. Хотя это по прежнему конечный объём, это довольно хороший лимит для начала. К сожалению, при этом ваш 16-ядерный сервер будет использовать только одно ядро для Redis. Что ж, как на счёт добавления по подчинённому процессу Redis на каждое ядро? Тогда у вас осталось по 15 ГБ памяти на каждый экземпляр. Опять фигня! Это плохое ограничение, если вы хотите иметь возможность выжать из сервера мощность. Это не достаточно данных для сервиса хостинга.
Мы решили спроектировать наше Redis-хранилище с самого начала разделённым среди множества Redis кластеров. Мы хэшируем и разделяем данные в блоки содержащие все структуры, относящиеся к данному сегменту данных. Данные сильно разделены с самого начала и мы можем по необходимости создавать новые блоки быстро и просто.
Для разбивки данных мы храним таблици хэшей и адресов примерно так:
Когда поступают данные, мы вычисляем хэш на основе наших требований к связности данных, потом мы проверяем в shards.map был ли он назначен какому-нибудь блоку, и если да — мы можем направить вызовы на тот блок.
Если хэш ещё не приписан к какому либо блоку, мы создаём список доступных блоков множа их в соответствии с весом. Если например выполнить:
Список будет выглядеть как-то так:
После этого мы назначаем случайный блок из списка, сохраняем в карту распределения и идём далее.
Применяя такую схему мы можем легко контролировать сколько данных поступает в блоки, добавлять новые блоки или даже исключать блоки из рассмотрения, если видим, что они заполнены.
Реально мы начали с сотен блоков так что нечего беспокоиться о нагрузке на сервера и ограничениях памяти.
Отдельные блоки остаются очень малыми. Один сервер содержит много блоков в базах данных Redis и, если эти блоки увеличиваются в размерах, мы легко можем разделить базы Redis на независимые экземпляры. Скажем у нас экземпляр Redis с 100 блоками, мы видим, что некоторые блоки увеличиваются в размере и мы разделяем Redis на два экземпляра по 50 блоков каждый. Мы можем точно настроить веса чтобы поддерживать распределение между блоками в реальном времени.
Самая сложная часть, это точно определить то, как вы сегментируете ваши данные. Это очень специфично и наш вариант сегментации, возможно, тема для отдельного поста.
Такая стратегия хранения должна разрабатываться в приложении с самого начала. Часто люди пытаются разделять данные, которые так не спроектированы, в этом то и загвоздка для их использования Redis. Поскольку мы чётко знали, что ограничение памяти будет проблемой, мы смогли спроектировать решение в самом ядре нашей системы управления данными, ещё до того как мы написали хоть одну строчку кода.
Падения сервера
Разобраться с отказами оказалось, смешно сказать, легче. У нас для кластера Redis было 3 разные роли:
— Мастер, где происходили почти все операции на запись,
— Подчинённый, гда происходили почти все чтения,
— Хранитель, выделенный для сохранения данных.
Мастер и подчинённый работают в общем как и любые другие в кластере Redis. В этом нет ничего интересного. Что мы сделали нового, это то что в каждом кластере есть по 2 сервера, используемых в качестве хранителей. Эти сервера:
— Не принимают никаких входящих соединений и не несут никакой нагрузки Redis запросов, кроме простой репликации
— Хранение AOF в ежесекундном режиме
— Ежечасный снимок RDB
— Синхронизируют AOF и RDB в S3
В виду того, что параметры производительности для хранения могут несколько различаться, один сервер хранитель может обработать различное количество блоков. Мы просто запускаем по одному экземпляру на каждый блок, который должен храниться. Другими словами, нет необходимости в отношении 1 к 1 между блоками и серверами с ролью хранителя.
У нас два этих сервера расположены в различных зонах доступности, так что даже если одна из зон выходит из строя, у нас есть работающий актуальный сервер-хранитель.
Таким образом, чтобы нам потерять данные необходим довольно большой отказ в EC2 и даже тогда, мы потеряем только около секунды данных.
Если вы рассматриваете сценарий нарушения связности сети, когда мастер может быть изолирован от подчинённых, его можно нивелировать проверкой репликации подчинённых(установить произвольный ключ в произвольное значение и проверить, обновились ли данные у подчинённого) Если мастер изолирован, мы останавливаем запись: Согласованность и Устойчивость к потере связности за счёт Доступности. Redis Sentinel тоже мог бы помочь нам с этим, но Sentinel был выпущен позже того, как мы реализовали большую часть системы. Мы не исследовали, как Sentinel мог бы вписаться бы в наше уравнение.
Конечный результат
В конце концов, мы смогли построить систему, которая под нагрузкой выполняет вызовы API за приблизительно 2 мс.
Значение 2 мс — при обслуживании нашего самого тяжёлого API-вызова, инициализационного API-вызова.
Многие наши запросы обслуживаются гораздо быстрее ( лайки например часто за 0.6-0.7 мс). Мы можем исполнять 1000 API запросов в секунду на одном API сервере. И для построения страницы требуется один API вызов. В замер включены все наши проверки данных, управление блоками, аутентификация, управление сессиями, соединениями, сериализация JSON и так далее.
Многое из этого заслуга не только ЭТИХ решений для Redis. Есть ещё несколько трюков для того, чтобы система производительно работала под высокой параллельной нагрузкой. Один из этик трюков в том, что почти половина нашего кода написана на Lua и работает прямо в Redis. Это другая вещь, которую в общем говорят не делать. Что касается того, как и почему у нас тысячи строк кода на Lua — подождите следующего поста о нашем применении Redis.
Взгляните на нашу реальную производительность, мы запустились пару дней назад, и получили неплохой начальный всплеск. Мы обслуживали 50 API вызовов в секунду и процессор нашего главного API сервера (мы до сих пор посылаем весь трафик на один) был полностью в простое. Вот графики, начиная с нашего запуска до момента написания поста.
Во время наших пиковых нагрузок всё тихо. Вы можете заметить пару всплесков, когда мы накатывали хотфиксы, но в остальном ни шороха. Более поздние всплески соответствуют обновлениям системы, исправлениям и другим проводимым системным работам. Общая нагрузка так же включает увеличенные накладные расходы на логгирование которое мы вели в период начального бета теста.
Пояснение: я ссылаюсь на API сервер как на замеряемый, так как наш сервер приложений и Redis сервер это одно и тоже. API сервер несёт на себе как несколько блоков, так и приложение. Идея была в том, чтобы маршрутизировать трафик на сервер где в основном расположен этот блок, чтобы воспользоваться unix-сокетами для подключения к Redis. Это позволят избегать излишнего сетевого трафика поэтому нет особого различия между Сервером приложений, Redis мастером и Redis подчинённым. Любой API сервер может обработать любой запрос, просто мы даём гораздо больший приоритет мастер серверу задействованного сегмента данных. Все серверы — серверы приложений, и все серверы — мастера для каких-то блоков и подчинённые для других.
tl;dr
Есть множество причин не использовать Redis как главное хранилище на жёстком диске, но если, по каким-то причинам, ваш вариант использования требует этого, вам необходимо начинать с самого начала. Вам стоит проектировать ваши данные разделёнными и помнить о дополнительной стоимости выделенных серверов хранения.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Redis
Redis (англ. REmote DIctionary Server ) — сетевое журналируемое хранилище данных типа «ключ — значение» с открытым исходным кодом. Нереляционная высокопроизводительная СУБД.
Содержание
Дизайн
Хранит базу данных в оперативной памяти, снабжена механизмами снимков и журналирования для обеспечения постоянного хранения (на диске). Также предоставляет операции для реализации механизма обмена сообщениями в паттерне publish — subscribe[en]. С его помощью приложения могут создавать каналы, подписываться на них и помещать в каналы сообщения, которые будут получены всеми подписчиками (как IRC-чат). Поддерживает репликацию данных с основных узлов на несколько подчинённых (англ. master — slave replication). Также Redis поддерживает транзакции (последовательное выполнение всех операций, либо ни одной) и пакетную обработку команд (выполнение пакета команд, получение пакета результатов).
В версии 2.6.0 добавлена поддержка Lua, позволяющего выполнять запросы на сервере. Lua позволяет атомарно совершить произвольную обработку данных на сервере и предназначена для использования в случае, когда нельзя достичь того же результата с использованием стандартных команд.
Поддерживаемые языки программирования
Множество языков программирования имеют библиотеки для работы с Redis: C, C++, C#, Clojure, Lisp, Erlang, Java, JavaScript, Haskell, Lua, Perl, PHP, Python, Ruby, Scala, Go, Tcl, Rust.
Модели данных
Все данные Redis хранит в виде словаря, в котором ключи связаны со своими значениями. Одно из ключевых отличий Redis от других хранилищ данных заключается в том, что значения этих ключей не ограничиваются строками. Поддерживаются следующие абстрактные типы данных:
Тип данных значения определяет, какие операции (команды) доступны для него. Redis поддерживает такие высокоуровневые операции, как объединение и разность наборов, а также их сортировку.
Настройка
Перед установкой Redis следует учесть пару нюансов. Для начала обновим пакеты apt-get:
По завершению процесса, установим компилятор с зависимыми пакетами, при помощи которого мы и установим Redis из исходного кода:
Наконец, скачает tcl:
Установка Redis
После необходимой подготовки, мы готовы приступить к установке Redis из исходников:
Далее выполните команду make:
Рекомендуется провести тест сборки:
Закончим, выполнив `make install`, в результате чего программа будет установлена глобально:
По завершению установки, мы получим Redis со встроенным скриптом для запуска сервера в качестве службы. Для доступа к скрипту перейдите в каталог utils:
Запустите скрипт из этого каталога:
Во время работы скрипта вы можете выбрать настройки по-умолчанию нажав enter. По окончанию работы скрипта Redis сервер будет запущен в фоновом режиме. Запустить и прервать работу сервера можно следующими командами (номер порта зависит от выбранного вами во время установки):
Получить доступ к БД Redis можно при помощи команды:
Ваш Redis сервер готов и запущен, подтверждением тому служит строка:
Для автоматического запуска сервера при загрузке системы выполните:
Чтобы вы не запутались и было более понятно, прикрепляю видео с установкой Redis на Ubuntu Server 14.04.4 LTS, а также показан пример записи и получения множества с сортировкой.
Операции Redis
Простейшая команда для добавления строковых данных (основной тип данных) может выглядеть так:
В этом случае за командой SET следует ключ (users:GeorgeWashington), а за ним значение (сама строка). Двоеточие в Redis не оказывает влияния на команду. Тем не менее его использование полезно для описания ключа.
Извлечь данные можно командой GET:
Диапазоны
Срок действия
Redis полезен в качестве хранилища в котором можно хранить данные с определённым сроком действия. Время действия может быть указано в секундах или в формате Unix timestamp (количество секунд с 1.1.1970).
Две команды для настройки:
При попытке выборки просроченных данных, мы получим nil
Инкремент
Redis поддерживает атомарный инкремент строковых данных. При работе инкремента доступ к данным блокируется, таким образом осуществляется целостность данных.
Транзакции
Redis также поддерживает выполнение транзакций, которые должны следовать двум принципам:
Команды должны выполняться по порядку. Они не будет прерваны другими запросами в течение всего процесса. Должна быть обеспечена целостность транзакции. Транзакции начинаются с команды MULTI, а запускаются командой EXEC. Если по каким-либо причинам транзакция прерывается, Redis заблокирует её выполнение до тех пор, пока не будет выполнена команда redis-check-aof и отменены все изменения. После этого сервер можно будет перезапустить:
Типы данных Redis
Redis работает с пятью типами данных: Strings (строки), Sets (множества), Sorted Sets (сортированные множества), Lists (списки), Hashes (хеш)
Строки
Множества
Примером использования множеств может быть проверка IP адреса посетителя сайт на уникальность или извлечение случайного значения командой SRANDMEMBER.
Множества с сортировкой
Такой тип данных часто применяется с диапазонами, так как добавление и удаление данных выполняется значительно быстрее. Часто встречаемые команды:
Списки
Добавление человека в начало очереди выглядит следующим образом:
Команда LRANGE выведет весь список:
Списка часто применяются для хранения временных событий или коллекции из ограниченного числа элементов.
Для получения определенной информации используйте команду HMGET
Восстановление данных
Репликация
Redis поддерживает репликацию типа master-slave. Данные с любого сервера Redis могут реплицироваться произвольное количество раз. Репликация полезна для масштабирования чтения (но не записи) или при очень больших объёмах данных. Все данные, которые попадают на один узел Redis (который называется master) будут попадать также на другие узлы (называются slave). Для конфигурирования slave-узлов можно изменить опцию slaveof или аналогичную по написанию команду (узлы, запущенные без подобных опций являются master-узлами).
Репликация помогает защитить данные, копируя их на другие сервера. Репликация также может быть использована для увеличения производительности, так как запросы на чтение могут обслуживаться slave-узлами. Эти узлы могут ответить слегка устаревшими данными, но для большинства приложений это приемлемо.
К сожалению, система репликации Redis еще не поддерживает автоматическую отказоустойчивость. Если master-узел выходит из строя, необходимо вручную выбрать новый master- из списка slave-узлов. Необходимо использовать Redis Sentinel для мониторинга и автоматического переключения master-узлов, если необходима устойчивая к сбоям система.
Пример создания реплики
Для создания реплики нам нужно две машины, с уже установленными Redis. Как установить его, уже было описано выше. На второй машине делаем то же самое, с одним лишь отличием: когда при установке запросит порт, пропишем не стандартный 6379, а любой другой, например 6380. Далее просто настраиваем связь master-slave, при помощи следующих программ. На машине master прописываем:
На машине slave прописываем:
Чтобы убедиться, можно просмотреть информацию о репликациях. На master:
Т.к. я использую виртуальные машины для реализации данной связи, то мне придётся предварительно настроить внутреннюю сеть и связать мои виртуальные машины, чтобы они могли связаться друг с другом.
Redis Sentinel
Redis Sentinel [7] — это система, разработанная для помощи в управлении узлами Redis. Она выполняет следующие задачи:
Sentinel не рекомендуется использовать в единственном экземпляре. Кластер Sentinel-узлов поддерживает кворум, благодаря чему, сохраняет работоспособность даже при переменном составе и временном отсутствии некоторых из них.
Redis и Memcached
На первый взгляд может показаться, что Redis мало чем отличается от Memcached. И Redis, и Memcached хранят данные в памяти и осуществляют доступ к ним по ключу. Оба написаны на Си и распространяются под лицензией BSD. Но в действительности, между ними больше различий, чем сходства.
В первую очередь, Redis умеет сохранять данные на диск. Можно настроить Redis так, чтобы данные вообще не сохранялись, сохранялись периодически по принципу copy-on-write или сохранялись периодически и писались в журнал (binlog). Таким образом, всегда можно добиться требуемого баланса между производительностью и надежностью.
Redis, в отличие от Memcached, позволяет хранить не только строки, но и массивы (которые могут использоваться в качестве очередей или стеков), словари, множества без повторов, большие массивы бит (bitmaps), а также множества, отсортированные по некой величине. Разумеется, можно работать с отдельными элементами списков, словарей и множеств. Как и Memcached, Redis позволяет указать время жизни данных (двумя способами — «удалить в заданный момент времени» и «удалить через заданный промежуток времени»). По умолчанию все данные хранятся вечно.
Интересная особенность Redis заключается в том, что это — однопоточный сервер. Такое решение сильно упрощает поддержку кода, обеспечивает атомарность операций и позволяет запустить по одному процессу Redis на каждое ядро процессора. Разумеется, каждый процесс будет прослушивать свой порт. Решение нетипичное, но вполне оправданное, так как на выполнение одной операции Redis тратит очень небольшое количество времени.
Производительность
Высокая производительность Redis обуславливается тем, что все данные хранятся в оперативной памяти. На Linux-сервере начального уровня был установлен результат в 110 000 запросов SET и 81 000 запросов GET в секунду(бенчмарк).