Кэш 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, или используйте георепликацию (в зависимости от бизнес-требований).
- Используйте одну статическую или отдельную реализацию мультиплексоров подключений к Redis и следуйте этому руководству.
- Изучите статью Администрирование Кэша Azure для Redis.
Рекомендации по настройке
Ознакомьтесь со следующей таблицей рекомендаций, чтобы оптимизировать конфигурацию Кэша Azure для Redis для обеспечения эффективности работы.
| Рекомендация | Описание |
|---|---|
| Запланируйте обновления. | Запланируйте дни и время для применения обновлений Redis Server к кэшу (не включают обновления Azure или обновления операционной системы виртуальных машин). |
| Отслеживайте кэш и настройте оповещения. | Настройте оповещения для исключений, высокой нагрузки на ЦП, высокой нагрузки на память, нагрузки на сервер и исключенных ключей, чтобы знать, когда следует масштабировать кэш. Очень важно понимать, в какое время вы будете выполнять масштабирование кэша, так как это увеличивает нагрузку на ЦП при миграции данных в ходе этого процесса. |
| Разверните кэш в виртуальной сети. | Предоставьте клиенту расширенные возможности управления трафиком, который может подключаться к кэшу. Убедитесь, что подсеть имеет достаточный диапазон адресов для развертывания узлов и сегментов (кластер) кэша. |
| Используйте в решении правильный тип кэширования (локальный, в роли, управляемый, Redis). | Распределенные приложения обычно реализуют одну или обе из следующих стратегий кэширования данных. — С помощью частного кэша, где данные хранятся локально на компьютере, где запущен экземпляр приложения или службы. — С помощью общего кэша, служащего общим источником, который может использоваться несколькими процессами и (или) компьютерами. В обоих случаях кэширование может быть выполнено на стороне клиента и сервера. Кэширование на стороне клиента выполняется процессом, предоставляющим пользовательский интерфейс для системы, например веб-браузер или классическое приложение. Кэширование на стороне сервера выполняется процессом, предоставляющим бизнес-службы, работающие удаленно. |
| Настройте сохраняемость данных, чтобы сохранять копию кэша в службе хранилища Azure, или используйте георепликацию (в зависимости от бизнес-требований). | Сохраняемость данных — если главный экземпляр и реплика будут перезапущены, данные автоматически загрузятся из учетной записи хранения. Георепликация — вторичный кэш нужно отвязать от первичного. Вторичный кэш теперь станет первичным и сможет принимать операции записи. |
| Изучите статью Администрирование Кэша Azure для Redis. | Узнайте, как могут возникать потери данных при перезапуске кэша и как протестировать приложение на устойчивость. |
Артефакты источника
Чтобы определить экземпляры Redis без уровня "Премиум", используйте следующий запрос:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'