Поделиться через


Кэш Azure для Redis и надежность

Кэш Azure для Redis предоставляет хранилище данных в памяти на основе программного обеспечения Redis (Remote Dictionary Server). Это защищенный кэш данных и брокер обмена сообщениями, который обеспечивает высокую пропускную способность и низкую задержку при обращении приложений к данным.

Основные понятия и рекомендации для поддержки устойчивости включают следующее:

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

Рекомендации по проектированию

Соглашение SLA для Кэша Azure для Redis распространяется только на кэши уровней "Стандартный" и "Премиум". Оно не применяется к уровню "Базовый".

Redis — это кэш в памяти для пар "ключ-значение", который по умолчанию имеет высокий уровень доступности (кроме уровня "Базовый"). Доступно три уровня Кэша Azure для Redis:

  • Базовый — не рекомендуется для производственных рабочих нагрузок. Уровень "Базовый" идеально подходит для следующих сценариев:

    • Один узел
    • Несколько размеров
    • Разработка
    • Тест
    • Некритические рабочие нагрузки
  • Стандартный — реплицированный кэш в конфигурации с двумя узлами (первичный и вторичный), управляемый Майкрософт, с SLA с высоким уровнем доступности.

  • Премиум — включает все функции уровня "Стандартный", а также следующие функции:

    • Более производительные функции и оборудование по сравнению с уровнями "Базовый" и "Стандартный".
    • Больший размер кэша, до 120GB.
    • Сохраняемость данных, в том числе на основе файлов базы данных Redis (RDB) и файлов только для добавления (AOF).
    • Поддержка виртуальной сети.
    • Кластеризация
    • Георепликация — вторичный кэш располагается в другом регионе и реплицирует данные из первичного кэша для аварийного восстановления. Чтобы выполнить отработку отказа на вторичный кэш, для кэшей необходимо вручную разорвать связь, после чего вторичный кэш станет доступен для операций записи. Приложение, которое записывает данные в Redis, нужно обновить с добавлением строки подключения к вторичному кэшу.
    • Зоны доступности — разверните кэш и реплики в зонах доступности.

      Примечание

      По умолчанию каждое развертывание будет иметь одну реплику на сегмент. Сохраняемость, кластеризация и георепликация сейчас отключены для развертываний с более чем одной репликой. Ваши узлы будут распределены равномерно по всем зонам. Число реплик должно быть >= числа зон.

    • Импорт и экспорт.

Корпорация Майкрософт гарантирует доступность по меньшей мере на уровне 99.9% для подключений между конечными точками кэша и Интернет-шлюзом Майкрософт.

Контрольный список

Настроили ли вы Кэш Azure для Redis с учетом устойчивости?


  • Запланируйте обновления.
  • Отслеживайте кэш и настройте оповещения.
  • Разверните кэш в виртуальной сети.
  • Оцените стратегию секционирования в кэше Redis.
  • Настройте сохраняемость данных, чтобы сохранять копию кэша в службе хранилища Azure, или используйте георепликацию (в зависимости от бизнес-требований).
  • Реализуйте политики повторных попыток в контексте своего Кэша Azure для Redis.
  • Используйте одну статическую или отдельную реализацию мультиплексоров подключений к Redis и следуйте этому руководству.
  • Изучите статью Администрирование Кэша Azure для Redis.

Рекомендации по настройке

Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации Кэша Azure для Redis, чтобы обеспечить надежность службы:

Рекомендация Описание
Запланируйте обновления. Запланируйте дни и время для применения обновлений Redis Server к кэшу (не включают обновления Azure или обновления операционной системы виртуальных машин).
Отслеживайте кэш и настройте оповещения. Настройте оповещения для исключений, высокой нагрузки на ЦП, высокой нагрузки на память, нагрузки на сервер и исключенных ключей, чтобы знать, когда следует масштабировать кэш. Очень важно понимать, в какое время вы будете выполнять масштабирование кэша, так как это увеличивает нагрузку на ЦП при миграции данных в ходе этого процесса.
Разверните кэш в виртуальной сети. Предоставьте клиенту расширенные возможности управления трафиком, который может подключаться к кэшу. Убедитесь, что подсеть имеет достаточный диапазон адресов для развертывания узлов и сегментов (кластер) кэша.
Оцените стратегию секционирования в кэше Redis. Секционирование хранилища данных Redis включает в себя разбиение данных по экземплярам сервера Redis. Каждый экземпляр образует одну секцию. Кэш Redis для Azure абстрагирует службы Redis в фоне и не предоставляет прямой доступ к ним. Самый простой способ реализации секционирования — создание нескольких экземпляров кэша Redis для Azure и распределение данных между ними. Каждый элемент данных можно связать с идентификатором (ключом секции), который указывает, в каком кэше его следует хранить. Логика клиентского приложения может использовать этот идентификатор для перенаправления запросов в соответствующую секцию. Эта схема проста, но при изменении схемы секционирования (например, если создаются дополнительные экземпляры Кэша Azure для Redis) может потребоваться изменение конфигурации клиентских приложений.
Настройте сохраняемость данных, чтобы сохранять копию кэша в службе хранилища Azure, или используйте георепликацию (в зависимости от бизнес-требований). Сохраняемость данных — если главный экземпляр и реплика будут перезапущены, данные автоматически загрузятся из учетной записи хранения. Георепликация — вторичный кэш нужно отвязать от первичного. Вторичный кэш теперь станет первичным и сможет принимать операции записи.
Реализуйте политики повторных попыток в контексте своего Кэша Azure для Redis. Большинство служб Azure и клиентских пакетов SDK содержат механизм повтора. Эти механизмы отличаются, так как каждая служба имеет разные характеристики и требования. Каждый механизм повтора адаптируется к конкретной службе.
Изучите статью Администрирование Кэша Azure для Redis. Узнайте, как могут возникать потери данных при перезапуске кэша и как протестировать приложение на устойчивость.

Артефакты источника

Чтобы определить экземпляры Redis без уровня "Премиум", используйте следующий запрос:

Resources 
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'

Следующий шаг