Архитектура Управляемого Redis (предварительная версия) Azure
Управляемый Redis (предварительная версия) Azure выполняется в стеке Redis Enterprise , который предоставляет значительные преимущества по сравнению с выпуском Redis сообщества. Ниже приведены более подробные сведения о архитектуре Управляемого Redis в Azure, включая сведения, которые могут быть полезны для пользователей.
Внимание
Управляемый Redis Azure в настоящее время находится в предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Сравнение с Кэш Azure для Redis
Уровни "Базовый", "Стандартный" и "Премиум" Кэш Azure для Redis были построены на выпуске Redis сообщества. Эта версия Redis имеет несколько существенных ограничений, включая однопотоковую разработку. Это значительно снижает производительность и делает масштабирование менее эффективным, так как больше виртуальных ЦП не полностью используются службой. Типичный экземпляр Кэш Azure для Redis использует архитектуру следующим образом:
Обратите внимание, что используются две виртуальные машины — основная и реплика. Эти виртуальные машины также называются узлами. Основной узел содержит основной процесс Redis и принимает все записи. Репликация выполняется асинхронно на узле реплики, чтобы обеспечить резервную копию во время обслуживания, масштабирования или непредвиденных сбоев. Каждый узел может выполнять только один процесс сервера Redis из-за однопоточного проектирования сообщества Redis.
Улучшения архитектуры Управляемого Redis в Azure
Управляемый Redis в Azure использует более расширенную архитектуру, которая выглядит примерно так:
Существует несколько различий:
- Каждая виртуальная машина (или узел) выполняет несколько процессов сервера Redis (называемых "сегментами") параллельно. Несколько сегментов позволяют более эффективно использовать виртуальные ЦП на каждой виртуальной машине и более высокую производительность.
- Не все основные сегменты Redis находятся на одной виртуальной машине или узле. Вместо этого первичные и реплики сегменты распределяются по обоим узлам. Так как первичные сегменты используют больше ресурсов ЦП, чем сегменты реплик, этот подход позволяет параллельно выполнять более первичные сегменты.
- Каждый узел имеет высокопроизводительный прокси-процесс для управления сегментами, обработки управления подключениями и активации самостоятельного восстановления.
Эта архитектура обеспечивает как более высокую производительность, так и расширенные функции, такие как активная георепликация
Кластеризация
Так как Redis Enterprise может использовать несколько сегментов на узел, каждый экземпляр Управляемого Redis Azure внутренне настроен для использования кластеризации на всех уровнях и номерах SKU. Это включает небольшие экземпляры, которые настроены только для использования одного сегмента. Кластеризация — это способ разделить данные в экземпляре Redis по нескольким процессам Redis, который также называется сегментированием. Управляемый Redis Azure предлагает две политики кластера, определяющие, какой протокол доступен клиентам Redis для подключения к экземпляру кэша.
Политики кластера
Управляемый Redis Azure предлагает два варианта для политики кластеризации: OSS и Enterprise. Для большинства приложений рекомендуется использовать политику кластера OSS , так как она поддерживает более высокую максимальную пропускную способность, но есть преимущества и недостатки для каждой версии.
Политика кластеризации OSS реализует тот же API кластера Redis, что и выпуск Redis для сообщества. API кластера Redis позволяет клиенту Redis подключаться непосредственно к сегментам на каждом узле Redis, минимизируя задержку и оптимизируя пропускную способность сети, что позволяет масштабировать почти линейно по мере увеличения количества сегментов и виртуальных ЦП. Политика кластеризации OSS обычно обеспечивает лучшую задержку и производительность пропускной способности. Однако политика кластера OSS требует, чтобы клиентская библиотека поддерживала API кластера Redis. Сегодня почти все клиенты Redis поддерживают API кластера Redis, но совместимость может быть проблемой для старых версий клиентов или специализированных библиотек. Политика кластеризации OSS также не может использоваться с модулем RediSearch.
Политика кластеризации предприятия — это более простая конфигурация, которая использует одну конечную точку для всех клиентских подключений. Использование политики кластеризации enterprise направляет все запросы к одному узлу Redis, который затем используется в качестве прокси-сервера, внутренние запросы маршрутизации на правильный узел в кластере. Преимущество этого подхода заключается в том, что это делает Управляемый Redis Azure некластеризованным для пользователей. Это означает, что клиентские библиотеки Redis не должны поддерживать кластеризацию Redis, чтобы получить некоторые преимущества производительности Redis Enterprise, повышая обратную совместимость и упрощая подключение. Недостатком является то, что прокси-сервер одного узла может быть узким местом в использовании вычислений или пропускной способности сети. Политика кластеризации enterprise является единственной, которая может использоваться с модулем RediSearch. Хотя политика кластера Enterprise делает экземпляр Azure Managed Redis некластеризованным для пользователей, он по-прежнему имеет некоторые ограничения с командами с несколькими ключами.
Масштабирование или добавление узлов
Основное программное обеспечение Redis Enterprise может выполнять масштабирование (с помощью более крупных виртуальных машин) или масштабирования (путем добавления дополнительных узлов или виртуальных машин). В конечном счете, любое действие масштабирования выполняет то же самое, добавляя больше памяти, больше виртуальных ЦП и больше сегментов. Из-за этой избыточности Управляемый Redis Azure не предлагает возможность контролировать определенное количество узлов, используемых в каждой конфигурации. Эта информация о реализации абстрагируется для пользователя, чтобы избежать путаницы, сложности и неоптимальных конфигураций. Вместо этого каждый номер SKU разработан с конфигурацией узла, чтобы максимально увеличить виртуальные ЦП и память. Некоторые номера SKU Управляемого Redis в Azure используют только два узла, а некоторые используют больше.
Команды с несколькими ключами
Так как экземпляры Управляемого Redis в Azure разработаны с кластеризованной конфигурацией, вы можете увидеть CROSSSLOT исключения команд, работающих с несколькими ключами. Поведение зависит от используемой политики кластеризации. Если используется политика кластеризации OSS, у команд с несколькими ключами необходимо сопоставить все ключи с одним хэш-слотом.
При использовании политики кластеризации Enterprise также могут возникнуть ошибки CROSSSLOT. Только следующие команды с несколькими ключами допускаются в слотах с кластеризацией Enterprise DEL, MSET, MGET, EXISTS, UNLINK и TOUCH.
В базах данных "активный — активный" команды записи с несколькими ключами (DEL, MSET, UNLINK) могут выполняться только с ключами, которые находятся в одном слоте. Однако в базах данных "активный — активный" разрешены следующие команды с несколькими ключами в разных слотах: MGET, EXISTS и TOUCH. Дополнительные сведения см. в разделе Кластеризация баз данных.
Конфигурация сегментирования
Каждый номер SKU Управляемого Redis в Azure настроен для запуска определенного количества процессов сервера Redis, сегментов параллельно. Связь между производительностью пропускной способности, числом сегментов и количеством виртуальных ЦП, доступными для каждого экземпляра, сложно. Добавление сегментов обычно повышает производительность, так как операции Redis могут выполняться параллельно. Однако если сегменты не могут выполнять команды, так как виртуальные ЦП не доступны для выполнения команд, производительность может удалиться. В следующей таблице показана конфигурация сегментирования для каждого SKU Управляемого Redis в Azure. Эти сегменты сопоставляются для оптимизации использования каждого виртуального ЦП при резервированию циклов виртуальных ЦП для прокси-сервера Redis Enterprise, агента управления и системных задач ОС, которые также влияют на производительность.
Примечание.
Количество сегментов и виртуальных ЦП, используемых в каждом номере SKU, может меняться с течением времени, так как производительность оптимизирована командой Управляемого Redis в Azure.
| Уровни | Оптимизированный для флэш-памяти | С оптимизацией для операций в памяти | Balanced | С оптимизацией для вычислений |
|---|---|---|---|---|
| Размер (ГБ) | виртуальные ЦП/первичные сегменты | виртуальные ЦП/первичные сегменты | виртуальные ЦП/первичные сегменты | виртуальные ЦП/первичные сегменты |
| 0,5 | - | - | 2/2 | - |
| 1 | - | - | 2/2 | - |
| 3 | - | - | 2/2 | 4/2 |
| 6 | - | - | 2/2 | 4/2 |
| 12 | - | 2/2 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 | 32/24 | 128/192 | 256/192 | - |
| 1440 | 48/48 | 192/192 | - | - |
| 1920 | 64/48 | 256/192 | - | - |
| 4500 | 144/96 | - | - | - |
Выполнение без включения режима высокой доступности
Режим высокой доступности (HA) можно выполнять без поддержки режима высокой доступности. Это означает, что экземпляр Redis не включает репликацию и не имеет доступа к соглашение об уровне обслуживания доступности. Не рекомендуется работать в режиме, отличном от высокого уровня доступности, за пределами сценариев разработки и тестирования. Вы не можете отключить высокий уровень доступности в созданном экземпляре. Вы можете включить высокий уровень доступности в экземпляре, который не имеет его, однако. Так как экземпляр, работающий без высокой доступности, использует меньше виртуальных машин и узлов, виртуальные ЦП не могут использоваться так эффективно, поэтому производительность может быть ниже.
Зарезервированная память
В каждом управляемом экземпляре Redis Azure приблизительно 20% доступной памяти зарезервировано в качестве буфера для операций, не относящихся к кэшу, таких как репликация во время отработки отказа и активного буфера георепликации. Этот буфер помогает повысить производительность кэша и предотвратить нехватку памяти.
Уменьшение масштаба
Масштабирование в настоящее время не поддерживается в Управляемом redis в Azure. Дополнительные сведения см. в статье о предварительных требованиях и ограничениях масштабирования Управляемого Redis в Azure.
Уровень "Оптимизировано для флэш-памяти"
Уровень "Оптимизированная для флэш-памяти" использует хранилище флэш-памяти NVMe и ОЗУ. Так как хранилище Флэш-памяти снижает затраты, используя уровень "Оптимизированная для флэш-памяти", вы можете свести на компромиссы с производительностью по цене.
В экземплярах, оптимизированных для флэш-памяти, 20 % кэша находится в ОЗУ, а в других 80% используется хранилище Flash. Все ключи хранятся в ОЗУ, а значения могут храниться в хранилище Флэш-памяти или ОЗУ. Программное обеспечение Redis интеллектуально определяет расположение значений. Горячие значения, к которым часто обращаются, хранятся в ОЗУ, а холодные значения, которые реже используются, хранятся в Flash. Прежде чем данные считываются или записываются, его необходимо переместить в ОЗУ, став горячими данными.
Так как Redis оптимизирует оптимальную производительность, экземпляр сначала заполняет доступную ОЗУ перед добавлением элементов в хранилище Flash. Заполнение ОЗУ в первую очередь имеет несколько последствий для производительности:
- Повышение производительности и снижение задержки могут возникать при тестировании с низким потреблением памяти. Тестирование с использованием полного экземпляра кэша может повысить производительность, так как только ОЗУ используется на этапе тестирования использования памяти с низким уровнем памяти.
- При записи дополнительных данных в кэш доля данных в ОЗУ по сравнению с хранилищем Флэш-памяти уменьшается, что обычно приводит к снижению производительности задержки и пропускной способности.
Рабочие нагрузки хорошо подходят для уровня "Оптимизированная для флэш-памяти"
Рабочие нагрузки, которые, скорее всего, будут работать хорошо на уровне "Оптимизировано для флэш-памяти", часто имеют следующие характеристики:
- Чтение с большим количеством операций чтения с высоким соотношением команд чтения для записи команд.
- Доступ ориентирован на подмножество ключей, которые используются гораздо чаще, чем остальная часть набора данных.
- Относительно большие значения по сравнению с именами ключей. (Так как имена ключей всегда хранятся в ОЗУ, большие значения могут стать узким местом для роста памяти.)
Рабочие нагрузки, которые не хорошо подходят для уровня "Оптимизировано для флэш-памяти"
Некоторые рабочие нагрузки имеют характеристики доступа, которые менее оптимизированы для проектирования оптимизированного уровня Flash:
- Написание тяжелых рабочих нагрузок.
- Случайные или универсальные шаблоны доступа к данным в большинстве наборов данных.
- Длинные имена ключей с относительно небольшими размерами значений.