Redis on windows что это
Обновлено: 04.07.2024
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 база данных, рассмотрите Amazon MemoryDB for Redi s . Поскольку MemoryDB использует надежный журнал транзакций, в котором хранятся данные нескольких зон доступности (AZ), вы можете задействовать ее в качестве основной базы данных. MemoryDB специально создана для того, чтобы разработчики могли работать с API Redis, не беспокоясь об управлении отдельным кэшем, базой данных или базовой инфраструктурой.
Высокая доступность и масштабируемость
Redis предлагает архитектуру «ведущий‑подчиненный» с одним ведущим узлом или с кластерной топологией. Это позволяет создавать высокодоступные решения, обеспечивающие стабильную производительность и надежность. Если требуется настроить размер кластера, доступны различные варианты вертикального и горизонтального масштабирования. В результате можно наращивать кластер в соответствии с потребностями.
Инструменты с открытым исходным кодом
Redis – проект с открытым исходным кодом, поддерживаемый активным сообществом, включая AWS. Поскольку 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 кластеров. Мы хэшируем и разделяем данные в блоки содержащие все структуры, относящиеся к данному сегменту данных. Данные сильно разделены с самого начала и мы можем по необходимости создавать новые блоки быстро и просто.
Для разбивки данных мы храним таблици хэшей и адресов примерно так:
Если хэш ещё не приписан к какому либо блоку, мы создаём список доступных блоков множа их в соответствии с весом. Если например выполнить:
Список будет выглядеть как-то так:
После этого мы назначаем случайный блок из списка, сохраняем в карту распределения и идём далее.
Применяя такую схему мы можем легко контролировать сколько данных поступает в блоки, добавлять новые блоки или даже исключать блоки из рассмотрения, если видим, что они заполнены.
Реально мы начали с сотен блоков так что нечего беспокоиться о нагрузке на сервера и ограничениях памяти.
Отдельные блоки остаются очень малыми. Один сервер содержит много блоков в базах данных 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 и так далее.
Серверы API, которые позволяют работать с такой нагрузкой, стоят всего $90 в месяц, так что мы можем поддерживать и горизонтально масштабировать довольно большие нагрузки по очень маленькой цене. Другая побочная польза от сильно разделённых на блоки данных, это то что горизонтальное масштабирование выполняется тривиально.
Многое из этого заслуга не только ЭТИХ решений для Redis. Есть ещё несколько трюков для того, чтобы система производительно работала под высокой параллельной нагрузкой. Один из этик трюков в том, что почти половина нашего кода написана на Lua и работает прямо в Redis. Это другая вещь, которую в общем говорят не делать. Что касается того, как и почему у нас тысячи строк кода на Lua — подождите следующего поста о нашем применении Redis.
Взгляните на нашу реальную производительность, мы запустились пару дней назад, и получили неплохой начальный всплеск. Мы обслуживали 50 API вызовов в секунду и процессор нашего главного API сервера (мы до сих пор посылаем весь трафик на один) был полностью в простое. Вот графики, начиная с нашего запуска до момента написания поста.
Во время наших пиковых нагрузок всё тихо. Вы можете заметить пару всплесков, когда мы накатывали хотфиксы, но в остальном ни шороха. Более поздние всплески соответствуют обновлениям системы, исправлениям и другим проводимым системным работам. Общая нагрузка так же включает увеличенные накладные расходы на логгирование которое мы вели в период начального бета теста.
Пояснение: я ссылаюсь на API сервер как на замеряемый, так как наш сервер приложений и Redis сервер это одно и тоже. API сервер несёт на себе как несколько блоков, так и приложение. Идея была в том, чтобы маршрутизировать трафик на сервер где в основном расположен этот блок, чтобы воспользоваться unix-сокетами для подключения к Redis. Это позволят избегать излишнего сетевого трафика поэтому нет особого различия между Сервером приложений, Redis мастером и Redis подчинённым. Любой API сервер может обработать любой запрос, просто мы даём гораздо больший приоритет мастер серверу задействованного сегмента данных. Все серверы — серверы приложений, и все серверы — мастера для каких-то блоков и подчинённые для других.
tl;dr
Есть множество причин не использовать Redis как главное хранилище на жёстком диске, но если, по каким-то причинам, ваш вариант использования требует этого, вам необходимо начинать с самого начала. Вам стоит проектировать ваши данные разделёнными и помнить о дополнительной стоимости выделенных серверов хранения.
ПОПРАВКА
Я только что понял, что я посчитал стоимость отдельного сервера и забыл добавить амортизированную единовременную стоимость зарезервированных экземпляров. Должно быть $213.
Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.
Рассмотрим следующие кейсы:
Кэширование данных
Давайте начнем с самого простого, один из самых популярных кейсов использования Redis — кэширование данных. Будет полезно для тех, кто не работал с Redis. Для тех, кто уже давно пользуется этим инструментом — можно смело переходить к следующему кейсу. Для того, чтобы снизить нагрузку на БД, иметь возможность запрашивать часто используемые данные максимально быстро, используется кэш. Redis — это in-memory хранилище, то есть данные хранятся в оперативной памяти. Ещё это key-value хранилище, где доступ к данным по их ключу имеет сложность O(1) — поэтому данные мы получаем очень быстро.
Получение данных из хранилища выглядит следующим образом:
Но для того, чтобы данные из кэша получить, их нужно сначала туда положить. Простой пример записи:
Таким образом, мы запишем данные в Redis и сможем их считать по тому же самому ключу в любой нужный нам момент. Но если мы будем все время писать в Redis, данные в нем будут занимать все больше и больше места в оперативной памяти. Нам нужно удалять нерелевантные данные, контролировать это вручную достаточно проблематично, поэтому пускай redis занимается этим самостоятельно. Добавим к нашему ключу TTL (время жизни ключа):
По истечении времени ttl (в секундах) данные по этому ключу будут автоматически удалены.
Как говорят, в программировании существует две самых сложных вещи: придумывание названий переменных и инвалидация кэша. Для того, чтобы принудительно удалить значение из Redis по ключу, достаточно выполнить следующую команду:
Также редис позволяет получить массив значений по списку ключей:
И соответственно массовое удаление данных по массиву ключей:
Очереди
Тем самым мы добавим в конец листа с названием $queueName некий $payload, который может представлять из себя JSON для инициализации нужной нам бизнес логики (например данные по денежной транзакции, данные для инициализации отправки письма пользователю, etc.). Если же в нашем хранилище не существует листа с именем $queueName, он будет автоматически создан, и туда попадет первый элемент $payload.
Со стороны консьюмера нам необходимо обеспечить получение задач из очереди, это реализуется простой командой чтения из листа. Для реализации FIFO очереди мы используем чтение с обратной записи стороны (в нашем случае мы писали через RPUSH), то есть читать будем через LPOP:
Для реализации LIFO очереди, нам нужно будет читать лист с той же стороны, с которой мы в него пишем, то есть через RPOP.
Для того, чтобы получить информацию о глубине очереди (сколько значений хранится в нашем листе), можем воспользоваться следующей командой:
Мы рассмотрели базовую реализацию простых очередей, но Redis позволяет строить более сложные очереди. Например, мы хотим знать о времени последней активности наших пользователей на сайте. Нам не важно знать это с точностью вплоть до секунды, приемлемая погрешность — 3 минуты. Мы можем обновлять поле last_visit пользователя при каждом запросе на наш бэкенд от этого пользователя. Но если этих пользователей большое количество в онлайне — 10,000 или 100,000? А если у нас еще и SPA, которое отправляет много асинхронных запросов? Если на каждый такой запрос обновлять поле в бд, мы получим большое количество тупых запросов к нашей БД. Эту задачу можно решать разными способами, один из вариантов — это сделать некую отложенную очередь, в рамках которой мы будем схлопывать одинаковые задачи в одну в определенном промежутке времени. Здесь на помощь нам придет такая структура, как Sorted SET. Это взвешенное множество, каждый элемент которого имеет свой вес (score). А что если в качестве score мы будем использовать timestamp добавления элемента в этот sorted set? Тогда мы сможем организовать очередь, в которой можно будет откладывать некоторые события на определенное время. Для этого используем следующую функцию:
В такой схеме идентификатор пользователя, зашедшего на сайт, попадет в очередь $queueName и будет висеть там в течение 180 секунд. Все другие запросы в рамках этого времени будут также отправляться в эту очередь, но они не будут туда добавлены, так как идентификатор этого пользователя уже существует в этой очереди и продублирован он не будет (за это отвечает параметр 'NX'). Так мы отсекаем всю лишнюю нагрузку и каждый пользователь будет генерить не более одного запроса в 3 минуты на обновление поля last_visit.
Теперь возникает вопрос о том, как читать эту очередь. Если методы 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 являются:
- $key — ключ идентифицирующий mutex;
- $hash — генерируем некую подпись, которая идентифицирует того, кто поставил mutex. Мы же не хотим, чтобы кто-то в другом месте случайно снял блокировку и вся наша логика рассыпалась.
- $ttl — время в секундах, которое мы отводим на блокировку (на тот случай, если что-то пойдет не так, например процесс, поставивший блокировку, по какой-то причине умер и не снял ее, чтобы это блокировка не висела бесконечно).
Чаще всего, когда мы пишем код, который пытается работать с shared ресурсом, который заблокирован, мы хотим дождаться его разблокировки и продолжить работу с этим ресурсом. Для этого можем реализовать простой метод для ожидания освободившегося ресурса:
Мы разобрались как ставить блокировку, теперь нам нужно научиться ее снимать. Для того, чтобы гарантировать снятие блокировки тем процессом, который ее установил, нам понадобится перед удалением значения из хранилища Redis, сверить хранимый хэш по этому ключу. Для того, чтобы сделать это атомарно, воспользуемся LUA скриптом:
Здесь мы пытаемся найти с помощью команды GET значение по ключу $key, если оно равно значению $hash, то удаляем его при помощи команды DEL, которая вернет нам количество удаленных ключей, если же значения по ключу $key не существует, или оно не равно значению $hash, то мы возвращаем 0, что значит блокировку снять не удалось. Базовый пример использования mutex:
Rate limiter
Достаточно частая задача, когда мы хотим ограничить количество запросов к нашему апи. Например на один API endpoint от одного аккаунта мы хотим принимать не более 100 запросов в минуту. Эта задача легко решается с помощью нашего любимого Redis:
Таким простым методом мы можем лимитировать количество запросов к нашему API, базовый каркас нашего контроллера мог бы выглядеть следующим образом:
Pub/sub
Redis — одна из самых популярных баз данных типа «ключ-значение», занимающая 4-е место по удовлетворенности пользователей базами данных NoSQL. Популярность Redis продолжает расти, и многие компании ищут разработчиков Redis на такие должности, как администратор базы данных и другие.
Что такое Redis?
Это расширенное хранилище данных типа «ключ-значение» в NoSQL, которое часто называют сервером структуры данных, поскольку его ключи содержат строки, хэши, списки, наборы, отсортированные наборы, точечные рисунки и гиперлоги. Операции чтения и записи Redis выполняются очень быстро, потому что данные хранятся в памяти. Данные также могут быть сохранены на диске или записаны обратно в память.
Поскольку Redis хранит свои данные в памяти, он чаще всего используется в качестве кеша. Некоторые крупные организации, использующие Redis, — это Twitter, GitHub, Instagram, Pinterest и Snapchat.
Преимущества Redis
Как установить Redis
Согласно официальной документации, рекомендуемый способ установки Redis — скомпилировать его из исходников. Сначала загрузите его с официального сайта, а затем скомпилируйте, выполнив следующие действия:
Затем вы можете протестировать свою сборку, набрав make test. srcКаталог будет заполнен исполняемым Redis.
Рекомендуется скопировать сервер Redis и интерфейс командной строки в нужные места, используя одну из двух стратегий.
- sudo make install
- Вручную с помощью следующих команд:
Оттуда запустите сервер Redis, выполнив redis-serverдвоичный файл (без аргументов). Поскольку нет явных файлов конфигурации, все параметры используют внутреннее значение по умолчанию. Это лучший способ начать, если вы новичок в Redis и хотите изучить среду.
Чтобы использовать Redis из вашего приложения, загрузите и установите клиентскую библиотеку Redis на основе языка программирования, который вы хотите использовать.
Типы данных Redis
Redis — это хранилище ключей и значений, но оно поддерживает многие типы структур данных в виде значений, отличных от строк. Ключ в Redis — это безопасная для двоичного кода строка с максимальным размером 512 МБ.
Давайте обсудим типы данных, которые поддерживаются в значениях.
String
Строка в Redis — это последовательность байтов. Они безопасны для двоичного кода, поэтому имеют известную длину, которая не определяется какими-либо завершающими символами. Вы можете хранить до 512 мегабайт в строке Redis. Он может хранить данные любого типа, такие как текст, целые числа, числа с плавающей запятой, видео, изображения или аудиофайлы.
В этом примере SETи GETпредставлены команды Redis, о которых мы поговорим позже. name- это ключ, а educativeэто строковое значение, которое мы храним.
В Redis списки — это списки строк, которые отсортированы по порядку вставки, поэтому элементы хранятся в связном списке. Вы можете добавлять элементы как на голове, так и на хвосте. Если нам нужно вставить элемент в список из 500 записей, это займет столько же времени, сколько и добавление элемента в список из 50 000 записей.
Вот несколько примеров операций для составления списка результирующих списков:
Наборы в Redis — это неупорядоченные коллекции строк. Этот тип значения аналогичен списку, но наборы не допускают дублирования, и элементы не сортируются ни в каком порядке. Вы можете добавлять или удалять участников вО (1)О ( 1 ) временная сложность.
Наборы полезны, когда мы хотим хранить данные, где важна уникальность. Например, сохранение количества уникальных посетителей веб-сайта.
Сортированные наборы
Мы можем сортировать элементы с типом значения Sorted Set. Каждый элемент будет связан с числом, которое мы называем счетом. Это определяет порядок.
Например, если у нас есть вызванный ключ vegetables, и мы хотим сохранить carrotи celeryв качестве значения. Оценка от carrot10 celeryдо 15. Первым будет морковь, затем сельдерей.
Если оценка двух разных элементов одинакова, мы проверяем, какая строка лексикографически больше.
В Redis тип хеш-значения — это пара значений поля. Они используются для представления объектов, но могут хранить множество элементов и полезны также для других задач. Хеш занимает очень мало места, поэтому вы можете хранить миллионы объектов в небольшом экземпляре хеша.
Фактически, хеш может хранить до ^ 2Взаимодействие с другими людьми3 2Взаимодействие с другими людьмиВзаимодействие с другими людьми- 1- 1 пары поле-значение, что составляет более 4 миллиардов.
Допустим, мы хотим хранить информацию об оценках студентов. Тема может быть ключевым. Значение может быть парой «поле-значение», где поле представляет собой имя учащегося, а значение — оценку каждого учащегося.
Вот еще один пример, чтобы познакомить вас с хешем Redis.
Команды Redis
Команды Redis используются для выполнения операций. Есть разные команды, которые мы можем применять к нашим различным типам данных. Ниже мы рассмотрим по одной команде для каждого типа данных, о котором говорилось выше, но имейте в виду, что в Redis существует множество команд.
Хранение строк в Redis
Самая простая форма данных, которая может храниться в базе данных Redis, — это строка. Мы рассмотрим две команды, используемые для хранения и выборки записей из базы данных Redis при использовании строк.
SET команда
Мы можем сохранить запись в Redis с помощью SETкоманды. Это установит ключ для хранения строкового значения. Если ключ уже содержит значение, оно будет перезаписано. Он имеет следующий синтаксис:
GET команда
Команда GETдает нам значение ключа. Если ключ не существует, он вернется nil. GETобрабатывает только строковые значения. Синтаксис:
Хранение списков в Redis
Мы также можем хранить списки, и база данных Redis хранит их в виде связанного списка. Когда мы вставляем новый элемент, мы можем вставить его либо в голову (крайний левый элемент), либо в хвост (крайний правый элемент). Мы рассмотрим две команды, используемые для добавления и удаления записей из головы при использовании списков.
LPUSH команда
Команда LPUSHиспользуется для вставки значения в начало списка. Мы можем использовать одно или несколько значений, а синтаксис следующий:
Примечание. Элементы вставляются в обратном порядке, потому что каждый элемент выбирается и вставляется в начале.
LPOP команда
Команда LPOP используется для удаления элемента из списка в начале (или слева).
Хранение наборов в Redis
Когда дело доходит до списка, мы допускаем дублирование элементов. Итак, если нам нужно добавить уникальные элементы, мы должны использовать набор, который хранится внутри как хеш-таблица. Это означает, что элементы хранятся случайным образом, и повторение не допускается. Давайте посмотрим на команду для добавления элемента из набора Redis.
SADD команда
Это позволяет нам добавлять указанные члены в набор, хранящийся под ключом. Если ключ не существует, создается новый набор.
Хранение отсортированных наборов в Redis
Элементы в наборе Redis не хранятся в каком-либо порядке. Итак, если мы хотим хранить элементы в отсортированном порядке, мы можем использовать отсортированные наборы, также называемые ZSets.
Перед вставкой каждому элементу должна быть присвоена оценка. База данных Redis сортирует элементы в порядке возрастания оценок. Посмотрим на команду добавления элементов в отсортированный набор.
ZADD команда
Эта команда добавит элементы в отсортированный набор в базе данных Redis. Мы можем указать несколько пар очков или членов. Если член уже находится в этом отсортированном наборе, оценка обновляется, и элемент повторно вставляется в правильную позицию для сохранения оценки. Вот синтаксис:
Хранение хэша в Redis
В Redis значение также может быть парой «поле-значение», которую мы называем хэш-структурой данных. Давайте посмотрим на команду для хранения хэша в Redis.
HMSET команда
Эта команда используется для хранения хэша в Redis. Он установит для полей соответствующие значения в хэше. Эта команда перезаписывает поля, которые уже существуют в хэше. Синтаксис этой команды:
При использовании Redis 4.0.0 HMSETсчитается устаревшим и HSETпредпочтительным.
Расширенные концепции Redis
Теперь, когда мы понимаем некоторые основы Redis и познакомились с командами, давайте рассмотрим некоторые дополнительные концепции.
Важное примечание о Redis
Для этого урока, вместо терминологии модель / Slave, мы будем использовать прогрессивную leader/ followerметафору. Использование нами этой терминологии не помешает вашему пониманию Redis.
Официальная документация Redis использует модель Master / Slave, которая преобладала в компьютерных науках на протяжении десятилетий, начиная с 1904 года.
В последние годы многие организации предприняли значительные усилия, чтобы противостоять этой проблемной метафоре и заменить ее.
В Educative мы верим в расширение возможностей разработчиков и изменение отрасли к лучшему. Использование инклюзивной терминологии является частью этого культурного сдвига.
Репликация данных в Redis
Когда данные хранятся на сервере и происходит сбой сервера, данные могут быть потеряны. Мы используем технику репликации данных, чтобы избежать этой проблемы. Это в основном означает, что данные хранятся на двух или более серверах, чтобы предотвратить потери или сбои. Репликация данных также снижает нагрузку на наши серверы, поскольку запросы пользователей балансируются по нагрузке.
Redis следует подходу лидера / подчиненного для репликации данных на сервере. Один из серверов — это a leader, а остальные — это серверы followers, которые все подключены к leader. Мы записываем все в каталог leader, который затем отправляет изменения в followers.
Если a followerотключен, он автоматически переподключится и leaderточно воспроизведет. Это можно сделать двумя способами:
- Частичная синхронизация.
- Полная синхронизация.
Примечание. В Redis процесс репликации асинхронный. Эти followerсервера асинхронно признают данные из leader, так что leaderзнает, какие команды были обработаны.
Упорство
Поскольку Redis — это база данных в памяти, данные хранятся в памяти (или ОЗУ). Если сервер выходит из строя, все сохраненные данные теряются. Redis имеет механизмы резервного копирования данных на диске. Таким образом, данные загружаются с диска в память при перезагрузке сервера. Redis имеет два варианта сохранения:
- Сохранение RDB (моментальные снимки): моментальные снимки данных хранятся на диске в dump.rdbфайле. Долговечность зависит от того, как часто данные выгружаются на диск.
- Сохранение файла только с добавлением (AOF): каждая операция записи, полученная сервером, регистрируется в файле, поэтому все команды в файле AOF запускаются снова при перезагрузке.
Кеширование на стороне клиента
Когда клиенту требуются данные, он просит сервер Redis предоставить их, что требует большой пропускной способности для каждого запроса. Мы можем кэшировать результаты для наиболее часто используемых ключей на стороне клиента, чтобы повысить производительность.
Redis обеспечивает поддержку кэширования на стороне клиента, которое называется отслеживанием. Есть два разных подхода:
Что учить дальше
Теперь вы должны хорошо понимать, как работает Redis и что он может сделать для ваших приложений. Это мощный инструмент, популярность которого растет. Любой разработчик должен обладать солидными навыками Redis в своем арсенале инструментов. Но есть еще чему поучиться.
Читайте также: