Redis как основная база данных для сложных приложений

Цель этой статьи — ответить на один вопрос: как можно использовать Redis в качестве основной базы данных для сложных приложений, которым необходимо хранить данные в нескольких форматах?

Сначала мы рассмотрим, что такое Redis и как он используется, а также почему он подходит для современных сложных микросервисных приложений. Разработчики компании DST Global расскажут о том, как Redis поддерживает хранение нескольких форматов данных для различных целей с помощью своих модулей. Далее мы увидим, как Redis, как база данных в памяти, может сохранять данные и восстанавливаться после потери данных. Мы также поговорим о том, как Redis оптимизирует затраты на хранение в памяти с помощью Redis на Flash.

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

Что такое Redis?

Redis, что на самом деле означает Remote Dictionary Server, — это база данных в памяти . Многие люди использовали ее в качестве кэша поверх других баз данных для повышения производительности приложений. Однако многие не знают, что Redis — это полноценная первичная база данных, которую можно использовать для хранения и сохранения нескольких форматов данных для сложных приложений.

Пример сложного приложения для социальных сетей

Давайте рассмотрим общую настройку для приложения микросервисов. Допустим, у нас есть сложное приложение социальных сетей с миллионами пользователей, с такой задачей разработчики компании DST Global сталкиваются регулярно создавая крупные маркетплейсы, экосистемы, порталы или социальные сети. И допустим, наше приложение микросервисов использует реляционную базу данных, например MySQL, для хранения данных. Кроме того, поскольку мы собираем тонны данных ежедневно, у нас есть база данных Elasticsearch для быстрой фильтрации и поиска данных.

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

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

1. Развертывание и обслуживание

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

2. Требования к масштабированию и инфраструктуре

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

3. Стоимость облака

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

4. Сложность разработки

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

5. Более высокая задержка

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

Почему Redis упрощает эту сложность

По сравнению с многомодальной базой данных, такой как Redis, вы решаете большинство следующих проблем:

- Единая служба данных . Вы запускаете и обслуживаете только одну службу данных. Поэтому ваше приложение также должно взаимодействовать с одним хранилищем данных, что означает только один программный интерфейс для этой службы данных.

- Сокращение задержки . Задержка будет уменьшена за счет перехода к единой конечной точке данных и исключения нескольких внутренних сетевых переходов.

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

Как Redis поддерживает несколько форматов данных

Итак, давайте посмотрим, как на самом деле работает Redis. Прежде всего, как Redis поддерживает несколько форматов данных в одной базе данных?

Ядро и модули Redis

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

- RedisSearch для функциональности поиска (как Elasticsearch)

- RedisGraph для хранения графических данных

Прелесть этого в том, что это модульно. Эти различные типы функциональности базы данных не тесно интегрированы в одну базу данных, как во многих других многомодальных базах данных, а, скорее, вы можете выбрать и точно выбрать, какая именно функциональность службы данных вам нужна для вашего приложения, а затем просто добавить этот модуль.

Встроенное кэширование

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

Высокая производительность и более быстрое тестирование

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

Сохранение данных в Redis

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

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

Моментальный снимок (RDB)

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

AOF (только добавление файла)

В качестве альтернативы Redis использует нечто под названием AOF, что означает Append Only File (добавить только файл ). В этом случае каждое изменение сохраняется на диске для постоянного сохранения. При перезапуске Redis или после сбоя Redis воспроизведет журналы Append Only File, чтобы восстановить состояние. Таким образом, AOF более долговечен, но может быть медленнее, чем моментальный снимок.

Комбинация снимков и AOF

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

Где находится это постоянное хранилище?

Очень интересный вопрос: где находится это постоянное хранилище? Так где же находится этот диск, на котором хранятся ваши снимки и журналы файлов только для добавления? Они находятся на тех же серверах, где работает Redis?

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

Конкретный пример: если ваши приложения и сервисы работают в облаке, скажем, на экземпляре AWS EC2, вам следует использовать EBS или Elastic Block Storage для сохранения ваших данных вместо того, чтобы хранить их на жестком диске экземпляра EC2. Потому что если этот экземпляр EC2 умрет, у вас не будет доступа ни к одному из его хранилищ, будь то оперативная память, дисковое хранилище или что-то еще.

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

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

Оптимизация затрат с Redis на Flash

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

На самом деле, в Redis есть способ оптимизировать это с помощью сервиса Redis on Flash, который является частью Redis Enterprise.

Как работает Redis на Flash

На самом деле, это довольно простая концепция: Redis на Flash расширяет ОЗУ до флэш-накопителя или SSD, где часто используемые значения хранятся в ОЗУ, а редко используемые — на SSD. Так что для Redis это просто больше ОЗУ на сервере. Это означает, что Redis может использовать больше базовой инфраструктуры или базовых ресурсов сервера, используя как ОЗУ, так и SSD-диск для хранения данных, увеличивая емкость хранилища на каждом сервере и таким образом экономя расходы на инфраструктуру.

Масштабирование Redis: репликация и шардинг

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

Репликация и высокая доступность

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

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

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

Шардинг для больших наборов данных

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

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

Это означает, что вместо того, чтобы иметь один главный экземпляр, который обрабатывает все записи в полный набор данных; вы можете разделить его, скажем, на четыре шарда, каждый из которых отвечает за чтение и запись в подмножество данных. Каждому шарду также требуется меньший объем памяти, поскольку он содержит только четверть данных. Это означает, что вы можете распределять и запускать шарды на меньших узлах и, по сути, масштабировать свой кластер горизонтально. И, конечно, по мере роста вашего набора данных и необходимости еще большего количества ресурсов вы можете повторно разбить свою базу данных Redis, что по сути означает, что вы просто разбиваете свои данные на еще более мелкие фрагменты и создаете больше шардов.

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

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

Глобальная репликация с Redis: активно-активное развертывание

Давайте рассмотрим еще один интересный сценарий для приложений, которым требуется еще более высокая доступность и производительность в нескольких географических точках. Итак, предположим, что у нас есть этот реплицированный, шардированный кластер базы данных Redis в одном регионе, в центре обработки данных в Лондоне, Европа. Но у нас есть два следующих варианта использования:

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

- Если, например, весь центр обработки данных в Лондоне, Европа, выйдет из строя, мы хотим немедленно переключиться на другой центр обработки данных, чтобы служба Redis оставалась доступной. Другими словами, мы хотим иметь копии всего кластера Redis в центрах обработки данных в нескольких географических точках или регионах.

Несколько кластеров Redis в разных регионах

Это означает, что отдельные данные должны быть реплицированы на множество кластеров, распределенных по нескольким регионам, при этом каждый кластер должен быть полностью способен принимать операции чтения и записи. В этом случае у вас будет несколько кластеров Redis, которые будут действовать как локальные экземпляры Redis в каждом регионе, и данные будут синхронизироваться по этим географически распределенным кластерам. Это функция, доступная в Redis Enterprise, и называется развертыванием «активный-активный», поскольку у вас есть несколько активных баз данных в разных местах.

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

Разрешение конфликтов с CRDT

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

В частности, Redis Enterprise использует концепцию CRDTs, которая означает «conflict-free replicated Data types» (бесконфликтные реплицированные типы данных), и эта концепция используется для автоматического разрешения любых конфликтов на уровне базы данных и без потери данных. Таким образом, по сути, сам Redis имеет механизм для слияния изменений, которые были внесены в один и тот же набор данных из нескольких источников таким образом, что ни одно из изменений данных не теряется, а любые конфликты разрешаются должным образом. И поскольку, как вы узнали, Redis поддерживает несколько типов данных, каждый тип данных использует свои собственные правила разрешения конфликтов данных, которые являются наиболее оптимальными для этого конкретного типа данных.

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

Запуск Redis в Kubernetes

И последняя тема, которую разработчики DST Global хотят затронуть в Redis, — это запуск Redis в Kubernetes . Как я уже сказал, Redis отлично подходит для сложных микросервисов, которым необходимо поддерживать несколько типов данных и которым необходимо легкое масштабирование базы данных без беспокойства о согласованности данных. И мы также знаем, что новым стандартом для запуска микросервисов является платформа Kubernetes. Итак, запуск Redis в Kubernetes — очень интересный и распространенный вариант использования. Так как же это работает?

Redis с открытым исходным кодом на Kubernetes

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

Redis Enterprise Оператор

Однако, как разработчики DST Global уже упоминали, многие команды не хотят прилагать усилия для поддержки этих сторонних сервисов, поскольку они предпочитают вкладывать свое время и ресурсы в разработку приложений или другие задачи. Поэтому наличие более простой альтернативы здесь также важно. Redis Enterprise имеет управляемый кластер Redis, который вы можете развернуть как оператор Kubernetes.

Если вы не знаете операторов, оператор в Kubernetes — это, по сути, концепция, в которой вы можете объединить все ресурсы, необходимые для работы определенного приложения или сервиса, чтобы вам не приходилось управлять им самостоятельно или вам не приходилось управлять им самостоятельно. Вместо того, чтобы человек управлял базой данных, у вас по сути есть вся эта логика в автоматизированной форме, чтобы управлять базой данных для вас. Во многих базах данных есть операторы для Kubernetes, и у каждого такого оператора, конечно, есть своя собственная логика, основанная на том, кто их написал и как они их написали.

Оператор Redis Enterprise on Kubernetes специально автоматизирует развертывание и настройку всей базы данных Redis в вашем кластере Kubernetes. Он также занимается масштабированием, созданием резервных копий и восстановлением кластера Redis при необходимости и т. д. Таким образом, он берет на себя полную работу кластера Redis внутри кластера Kubernetes.