Руководство по кэшированию

Кэш Azure для Redis

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

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

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

Кэширование в распределенных приложениях

Распределенные приложения обычно реализуют один или оба из следующих стратегий при кэшировании данных:

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

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

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

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

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

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

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

Результаты использования кэша в памяти в разных экземплярах приложения

Рис. 1. Использование кэша в памяти в разных экземплярах приложения.

Общий кэширование

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

Результаты использования общего кэша

Рис. 2. Использование общего кэша.

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

Существует два основных недостатка общего подхода кэширования:

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

Управление параллелизмом в кэше

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

В зависимости от характера данных и вероятности конфликтов можно применить один из двух подходов к параллелизму:

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

Реализация высокой доступности и масштабируемости и повышение производительности

Избегайте использования кэша в качестве основного репозитория данных; это роль исходного хранилища данных, из которого заполняется кэш. Исходное хранилище данных отвечает за сохранение данных.

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

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

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

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

Этот подход требует тщательной настройки, чтобы предотвратить слишком устаревший локальный кэш в отношении общего кэша. Однако локальный кэш выступает в качестве буфера, если общий кэш недоступен. На рисунке 3 показана эта структура.

Использование локального частного кэша с общим кэшем

Рис. 3. Использование локального частного кэша с общим кэшем.

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

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

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

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

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

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

Кэширование и итоговая согласованность

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

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

Дополнительные сведения об обработке согласованности данных см. в праймере согласованности данных.

Защита кэшированных данных

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

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

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

Какие удостоверения могут получить доступ к данным в кэше.
Какие операции (чтение и запись) разрешены для выполнения этих удостоверений.

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

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

Разделите кэш на секции (с помощью разных серверов кэша) и предоставьте доступ только удостоверениям для секций, которые они должны использовать.
Зашифруйте данные в каждом подмножестве с помощью разных ключей и предоставьте ключи шифрования только удостоверениям, которые должны иметь доступ к каждому подмножество. Клиентское приложение по-прежнему может получить все данные в кэше, но только сможет расшифровать данные, для которых он имеет ключи.

Кроме того, необходимо защитить данные при его выходе из кэша. Для этого зависит от функций безопасности, предоставляемых сетевой инфраструктурой, используемой клиентскими приложениями для подключения к кэшу. Если кэш реализуется с помощью локального сервера в той же организации, где размещаются клиентские приложения, изоляция самой сети может не потребовать дополнительных действий. Если кэш находится удаленно и требует подключения TCP или HTTP через общедоступную сеть (например, Интернет), рассмотрите возможность реализации SSL.

Кэширование состояния сеанса и выходных данных HTML

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

Использование поставщика состояний сеанса с кэшем Azure для Redis обеспечивает несколько преимуществ, в том числе:

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

Дополнительные сведения см. в разделе ASP.NET поставщик состояния сеанса для кэша Azure для Redis.

Замечание

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

Аналогичным образом поставщик кэша выходных данных для Кэша Azure для Redis позволяет сохранять HTTP-ответы, созданные веб-приложением ASP.NET. Использование поставщика кэша выходных данных с кэшем Azure для Redis может улучшить время отклика приложений, которые отображают сложные выходные данные HTML. Экземпляры приложений, которые создают аналогичные ответы, могут использовать общие выходные фрагменты в кэше, а не создавать эти выходные данные HTML. Дополнительные сведения см. в разделе ASP.NET поставщика кэша выходных данных для Кэша Azure для Redis.

Создание пользовательского кэша Redis

Кэш Azure для Redis выступает в качестве фасада для базовых серверов Redis. Если требуется расширенная конфигурация, которая не охватывается кэшем Redis Azure (например, кэш размером более 53 ГБ), можно создавать и размещать собственные серверы Redis с помощью виртуальных машин Azure.

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

Каждая первичная или подчиненная пара должна находиться близко друг к другу, чтобы свести к минимуму задержку. Однако каждый набор пар может выполняться в разных центрах обработки данных Azure, расположенных в разных регионах, если вы хотите найти кэшированные данные близко к приложениям, которые, скорее всего, будут использовать его. Пример создания и настройки узла Redis, работающего как виртуальная машина Azure, см. в статье "Запуск Redis" на виртуальной машине Linux CentOS в Azure.

Замечание

Если вы реализуете собственный кэш Redis таким образом, вы несете ответственность за мониторинг, управление и защиту службы.

Секционирование кэша Redis

Секционирование кэша включает разделение кэша на нескольких компьютерах. Эта структура дает несколько преимуществ по сравнению с одним сервером кэша, включая:

Создание кэша, который гораздо больше, чем может храниться на одном сервере.
Распределение данных между серверами, повышение доступности. Если один сервер завершается сбоем или становится недоступным, данные, которые он содержит, недоступны, но доступ к данным на оставшихся серверах по-прежнему можно получить. Для кэша это не важно, так как кэшированные данные — это только временная копия данных, которые хранятся в базе данных. Кэшированные данные на сервере, который становится недоступным, можно кэшировать на другом сервере.
Распределение нагрузки между серверами, тем самым повышая производительность и масштабируемость.
Геолокация данных близко к пользователям, к которым он обращается, что снижает задержку.

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

Чтобы реализовать секционирование в кэше Redis, можно использовать один из следующих подходов:

Маршрутизация запросов на стороне сервера. В этом методе клиентское приложение отправляет запрос на любой из серверов Redis, составляющих кэш (вероятно, ближайший сервер). Каждый сервер Redis хранит метаданные, описывающие удерживаемую секцию, а также содержит сведения о том, какие секции находятся на других серверах. Сервер Redis проверяет запрос клиента. Если ее можно разрешить локально, она выполнит запрошенную операцию. В противном случае он перенаправит запрос на соответствующий сервер. Эта модель реализована кластеризированием Redis и подробно описана на странице руководства по кластеру Redis на веб-сайте Redis. Кластеризация Redis является прозрачной для клиентских приложений, а дополнительные серверы Redis можно добавить в кластер (и повторное развертывание данных), не требуя перенастройки клиентов.
Секционирование на стороне клиента. В этой модели клиентское приложение содержит логику (возможно, в виде библиотеки), которая направляет запросы на соответствующий сервер Redis. Этот подход можно использовать с кэшем Azure для Redis. Создайте несколько кэша Azure для Redis (по одному для каждой секции данных) и реализуйте клиентская логика, которая направляет запросы в правильный кэш. Если схема секционирования изменяется (если создается дополнительный кэш Azure для Redis, например), клиентские приложения могут быть перенастроены.
Секционирование с помощью прокси-сервера. В этой схеме клиентские приложения отправляют запросы в промежуточную прокси-службу, которая понимает, как данные секционируются, а затем направляет запрос на соответствующий сервер Redis. Этот подход также можно использовать с кэшем Azure для Redis; Прокси-служба может быть реализована как облачная служба Azure. Этот подход требует дополнительного уровня сложности для реализации службы, и запросы могут занять больше времени, чем использование секционирования на стороне клиента.

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

Реализация клиентских приложений кэша Redis

Redis поддерживает клиентские приложения, написанные на многочисленных языках программирования. При создании новых приложений с помощью .NET Framework рекомендуется использовать клиентская библиотека StackExchange.Redis. Эта библиотека предоставляет объектную модель .NET Framework, которая абстрагирует сведения о подключении к серверу Redis, отправке команд и получении ответов. Он доступен в Visual Studio в виде пакета NuGet. Эту же библиотеку можно использовать для подключения к кэшу Azure для Redis или пользовательскому кэшу Redis, размещенному на виртуальной машине.

Для подключения к серверу Redis используется статический Connect метод ConnectionMultiplexer класса. Созданное этим методом соединение предназначено для использования в течение всего времени существования клиентского приложения, а одно и то же подключение может использоваться несколькими параллельными потоками. Не подключайтесь и не отключайтесь при каждом выполнении операции Redis, так как это может снизить производительность.

Можно указать параметры подключения, такие как адрес узла Redis и пароль. При использовании кэша Azure для Redis пароль является первичным или вторичным ключом, созданным для кэша Azure для Redis с помощью портала Azure.

После подключения к серверу Redis можно получить дескриптор в базе данных Redis, которая выступает в качестве кэша. Подключение Redis предоставляет GetDatabase метод для этого. Затем можно извлечь элементы из кэша и сохранить данные в кэше с помощью StringGet методов и StringSet методов. Эти методы ожидают ключ в качестве параметра и возвращают элемент в кэше с соответствующим значением (StringGet) или добавьте элемент в кэш с этим ключом (StringSet).

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

В следующем фрагменте кода показан метод с именем RetrieveItem. Он иллюстрирует реализацию шаблона в стороне кэша на основе Redis и библиотеки StackExchange. Метод принимает строковое значение ключа и пытается получить соответствующий элемент из кэша Redis путем вызова StringGetAsync метода (асинхронная версия StringGet).

Если элемент не найден, он извлекается из базового источника данных с помощью GetItemFromDataSourceAsync метода (который является локальным методом, а не частью библиотеки StackExchange). Затем он добавляется в кэш с помощью StringSetAsync метода, чтобы его можно было получить быстрее при следующем запуске.

// Connect to the Azure Redis cache
ConfigurationOptions config = new ConfigurationOptions();
config.EndPoints.Add("<your DNS name>.redis.cache.windows.net");
config.Password = "<Redis cache key from management portal>";
ConnectionMultiplexer redisHostConnection = ConnectionMultiplexer.Connect(config);
IDatabase cache = redisHostConnection.GetDatabase();
...
private async Task<string> RetrieveItem(string itemKey)
{
    // Attempt to retrieve the item from the Redis cache
    string itemValue = await cache.StringGetAsync(itemKey);

    // If the value returned is null, the item was not found in the cache
    // So retrieve the item from the data source and add it to the cache
    if (itemValue == null)
    {
        itemValue = await GetItemFromDataSourceAsync(itemKey);
        await cache.StringSetAsync(itemKey, itemValue);
    }

    // Return the item
    return itemValue;
}

StringSet Методы StringGet не ограничиваются извлечением или хранением строковых значений. Они могут принимать любой элемент, сериализованный в виде массива байтов. Если необходимо сохранить объект .NET, его можно сериализовать в виде потока байтов и использовать StringSet метод для записи в кэш.

Аналогичным образом можно считывать объект из кэша StringGet с помощью метода и десериализации его в виде объекта .NET. В следующем коде показан набор методов расширения для интерфейса IDatabase ( GetDatabase метод подключения Redis возвращает IDatabase объект), а также некоторый пример кода, который использует эти методы для чтения и записи BlogPost объекта в кэш:

public static class RedisCacheExtensions
{
    public static async Task<T> GetAsync<T>(this IDatabase cache, string key)
    {
        return Deserialize<T>(await cache.StringGetAsync(key));
    }

    public static async Task<object> GetAsync(this IDatabase cache, string key)
    {
        return Deserialize<object>(await cache.StringGetAsync(key));
    }

    public static async Task SetAsync(this IDatabase cache, string key, object value)
    {
        await cache.StringSetAsync(key, Serialize(value));
    }

    static byte[] Serialize(object o)
    {
        byte[] objectDataAsStream = null;

        if (o != null)
        {
            var jsonString = JsonSerializer.Serialize(o);
            objectDataAsStream = Encoding.ASCII.GetBytes(jsonString);
        }

        return objectDataAsStream;
    }

    static T Deserialize<T>(byte[] stream)
    {
        T result = default(T);

        if (stream != null)
        {
            var jsonString = Encoding.ASCII.GetString(stream);
            result = JsonSerializer.Deserialize<T>(jsonString);
        }

        return result;
    }
}

Следующий код иллюстрирует метод с именем RetrieveBlogPost , использующий эти методы расширения для чтения и записи сериализуемого BlogPost объекта в кэш после шаблона в сторону кэша:

// The BlogPost type
public class BlogPost
{
    private HashSet<string> tags;

    public BlogPost(int id, string title, int score, IEnumerable<string> tags)
    {
        this.Id = id;
        this.Title = title;
        this.Score = score;
        this.tags = new HashSet<string>(tags);
    }

    public int Id { get; set; }
    public string Title { get; set; }
    public int Score { get; set; }
    public ICollection<string> Tags => this.tags;
}
...
private async Task<BlogPost> RetrieveBlogPost(string blogPostKey)
{
    BlogPost blogPost = await cache.GetAsync<BlogPost>(blogPostKey);
    if (blogPost == null)
    {
        blogPost = await GetBlogPostFromDataSourceAsync(blogPostKey);
        await cache.SetAsync(blogPostKey, blogPost);
    }

    return blogPost;
}

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

Этот подход помогает сократить задержку, делая более эффективным использование сети. В следующем фрагменте кода показан пример, который извлекает сведения о двух клиентах одновременно. Код отправляет два запроса, а затем выполняет другую обработку (не отображается), прежде чем ожидать получения результатов. Метод Wait объекта кэша аналогичен методу .NET Framework Task.Wait :

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
var task1 = cache.StringGetAsync("customer:1");
var task2 = cache.StringGetAsync("customer:2");
...
var customer1 = cache.Wait(task1);
var customer2 = cache.Wait(task2);

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

На одном веб-сайте конвейеры и мультиплексоры страницы содержатся дополнительные сведения об асинхронных операциях и конвейерах с помощью Redis и библиотеки StackExchange.

Использование кэширования Redis

Самое простое использование Redis для проблем кэширования — это пары "ключ-значение", где значение является непреднамереной строкой произвольной длины, которая может содержать любые двоичные данные. (Это, по сути, массив байтов, которые можно рассматривать как строку). Этот сценарий показан в разделе "Реализация клиентских приложений кэша Redis" ранее в этой статье.

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

Например, используйте структурированные ключи, такие как customer:100, чтобы представить ключ для клиента с идентификатором 100, а не просто "100". Эта схема позволяет легко различать значения, которые хранят разные типы данных. Например, можно также использовать ключ "orders:100", чтобы представить ключ для заказа с идентификатором 100.

Помимо одномерных двоичных строк, значение в паре "Ключ-значение Redis" также может содержать более структурированные сведения, включая списки, наборы (отсортированные и несортированные) и хэши. Redis предоставляет полный набор команд, который может управлять этими типами, и многие из этих команд доступны для приложений .NET Framework через клиентская библиотека, например StackExchange. Страница Введение в типы данных Redis и абстракции на веб-сайте Redis содержит более подробный обзор этих типов и команд, которые можно использовать для управления ими.

В этом разделе приведены некоторые распространенные варианты использования этих типов данных и команд.

Выполнение атомарных и пакетных операций

Redis поддерживает ряд атомарных операций получения и задания строковых значений. Эти операции удаляют возможные риски расы, которые могут возникать при использовании отдельных GET команд и SET команд. Доступные операции:

INCR, , INCRBYDECRи DECRBY, которые выполняют атомарные инкрементные операции с целыми числовыми значениями данных. Библиотека StackExchange предоставляет перегруженные версии и IDatabase.StringDecrementAsync методы IDatabase.StringIncrementAsync для выполнения этих операций и возврата результирующего значения, хранящегося в кэше. В следующем фрагменте кода показано, как использовать следующие методы:
```
ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
await cache.StringSetAsync("data:counter", 99);
...
long oldValue = await cache.StringIncrementAsync("data:counter");
// Increment by 1 (the default)
// oldValue should be 100

long newValue = await cache.StringDecrementAsync("data:counter", 50);
// Decrement by 50
// newValue should be 50
```
GETSET, который получает значение, связанное с ключом, и изменяет его на новое значение. Библиотека StackExchange делает эту операцию доступной IDatabase.StringGetSetAsync с помощью метода. В приведенном ниже фрагменте кода показан пример этого метода. Этот код возвращает текущее значение, связанное с ключом data:counter из предыдущего примера. Затем он сбрасывает значение для этого ключа обратно к нулю, все в рамках одной операции:
```
ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string oldValue = await cache.StringGetSetAsync("data:counter", 0);
```

MGET и MSET, которое может возвращать или изменять набор строковых значений в виде одной операции. IDatabase.StringSetAsync Методы IDatabase.StringGetAsync перегружены для поддержки этой функции, как показано в следующем примере:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Create a list of key-value pairs
var keysAndValues =
    new List<KeyValuePair<RedisKey, RedisValue>>()
    {
        new KeyValuePair<RedisKey, RedisValue>("data:key1", "value1"),
        new KeyValuePair<RedisKey, RedisValue>("data:key99", "value2"),
        new KeyValuePair<RedisKey, RedisValue>("data:key322", "value3")
    };

// Store the list of key-value pairs in the cache
cache.StringSet(keysAndValues.ToArray());
...
// Find all values that match a list of keys
RedisKey[] keys = { "data:key1", "data:key99", "data:key322"};
// values should contain { "value1", "value2", "value3" }
RedisValue[] values = cache.StringGet(keys);

Вы также можете объединить несколько операций в одну транзакцию Redis, как описано в разделе транзакций Redis и пакетных пакетов, описанных ранее в этой статье. Библиотека StackExchange обеспечивает поддержку транзакций ITransaction через интерфейс.

Объект создается ITransaction с помощью IDatabase.CreateTransaction метода. Команды для транзакции вызываются с помощью методов, предоставляемых ITransaction объектом.

Интерфейс ITransaction предоставляет доступ к набору методов, которые похожи на те, к которым обращается IDatabase интерфейс, за исключением того, что все методы являются асинхронными. Это означает, что они выполняются только при вызове ITransaction.Execute метода. Значение, возвращаемое методом ITransaction.Execute , указывает, успешно ли была создана транзакция (true) или если она завершилась ошибкой (false).

В следующем фрагменте кода показан пример, который увеличивает и уменьшает два счетчика в рамках одной транзакции:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
ITransaction transaction = cache.CreateTransaction();
var tx1 = transaction.StringIncrementAsync("data:counter1");
var tx2 = transaction.StringDecrementAsync("data:counter2");
bool result = transaction.Execute();
Console.WriteLine("Transaction {0}", result ? "succeeded" : "failed");
Console.WriteLine("Result of increment: {0}", tx1.Result);
Console.WriteLine("Result of decrement: {0}", tx2.Result);

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

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

Дополнительные сведения см. в разделе "Транзакции" в Redis.

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

Объект создается IBatch с помощью IDatabase.CreateBatch метода, а затем выполняется пакет с помощью IBatch.Execute метода, как показано в следующем примере. Этот код просто задает строковое значение, увеличивает и уменьшает те же счетчики, используемые в предыдущем примере, и отображает результаты:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
IBatch batch = cache.CreateBatch();
batch.StringSetAsync("data:key1", 11);
var t1 = batch.StringIncrementAsync("data:counter1");
var t2 = batch.StringDecrementAsync("data:counter2");
batch.Execute();
Console.WriteLine("{0}", t1.Result);
Console.WriteLine("{0}", t2.Result);

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

Выполнение операций с огнем и забыли об операциях кэша

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

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
await cache.StringSetAsync("data:key1", 99);
...
cache.StringIncrement("data:key1", flags: CommandFlags.FireAndForget);

Укажите автоматически истекающий срок действия ключей

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

В следующем фрагменте кода показано, как задать время окончания срока действия ключа в течение 20 секунд и запросить оставшееся время существования ключа:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration time of 20 seconds
await cache.StringSetAsync("data:key1", 99, TimeSpan.FromSeconds(20));
...
// Query how much time a key has left to live
// If the key has already expired, the KeyTimeToLive function returns a null
TimeSpan? expiry = cache.KeyTimeToLive("data:key1");

Вы также можете задать время окончания срока действия для определенной даты и времени с помощью команды EXPIRE, которая доступна в библиотеке StackExchange в качестве KeyExpireAsync метода:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration date of midnight on 1st January 2015
await cache.StringSetAsync("data:key1", 99);
await cache.KeyExpireAsync("data:key1",
    new DateTime(2015, 1, 1, 0, 0, 0, DateTimeKind.Utc));
...

Подсказка

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

Использование тегов для перекрестной корреляции кэшированных элементов

Набор Redis — это коллекция нескольких элементов, которые совместно используют один ключ. Вы можете создать набор с помощью команды SADD. Элементы в наборе можно получить с помощью команды SMEMBERS. Библиотека StackExchange реализует команду SADD с IDatabase.SetAddAsync методом и команду SMEMBERS с методом IDatabase.SetMembersAsync .

Вы также можете объединить существующие наборы для создания новых наборов с помощью команд SDIFF (set difference), SINTER (set intersection) и SUNION (set union). Библиотека StackExchange объединяет эти операции в методе IDatabase.SetCombineAsync . Первый параметр этого метода указывает операцию набора, выполняемую.

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

Объект BlogPost содержит четыре поля: идентификатор, название, оценка ранжирования и коллекция тегов. В первом фрагменте кода ниже показаны примеры данных, которые используются для заполнения списка BlogPost объектов C#:

List<string[]> tags = new List<string[]>
{
    new[] { "iot","csharp" },
    new[] { "iot","azure","csharp" },
    new[] { "csharp","git","big data" },
    new[] { "iot","git","database" },
    new[] { "database","git" },
    new[] { "csharp","database" },
    new[] { "iot" },
    new[] { "iot","database","git" },
    new[] { "azure","database","big data","git","csharp" },
    new[] { "azure" }
};

List<BlogPost> posts = new List<BlogPost>();
int blogKey = 0;
int numberOfPosts = 20;
Random random = new Random();
for (int i = 0; i < numberOfPosts; i++)
{
    blogKey++;
    posts.Add(new BlogPost(
        blogKey,                  // Blog post ID
        string.Format(CultureInfo.InvariantCulture, "Blog Post #{0}",
            blogKey),             // Blog post title
        random.Next(100, 10000),  // Ranking score
        tags[i % tags.Count]));   // Tags--assigned from a collection
                                  // in the tags list
}

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

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Tags are easily represented as Redis Sets
foreach (BlogPost post in posts)
{
    string redisKey = string.Format(CultureInfo.InvariantCulture,
        "blog:posts:{0}:tags", post.Id);
    // Add tags to the blog post in Redis
    await cache.SetAddAsync(
        redisKey, post.Tags.Select(s => (RedisValue)s).ToArray());

    // Now do the inverse so we can figure out which blog posts have a given tag
    foreach (var tag in post.Tags)
    {
        await cache.SetAddAsync(string.Format(CultureInfo.InvariantCulture,
            "tag:{0}:blog:posts", tag), post.Id);
    }
}

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

// Show the tags for blog post #1
foreach (var value in await cache.SetMembersAsync("blog:posts:1:tags"))
{
    Console.WriteLine(value);
}

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

// Show the tags in common for blog posts #1 and #2
foreach (var value in await cache.SetCombineAsync(SetOperation.Intersect, new RedisKey[]
    { "blog:posts:1:tags", "blog:posts:2:tags" }))
{
    Console.WriteLine(value);
}

И вы можете найти все записи блога, содержащие определенный тег:

// Show the ids of the blog posts that have the tag "iot".
foreach (var value in await cache.SetMembersAsync("tag:iot:blog:posts"))
{
    Console.WriteLine(value);
}

Поиск недавно доступных элементов

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

Эту функцию можно реализовать с помощью списка Redis. Список Redis содержит несколько элементов, которые используют один и тот же ключ. Список выступает в качестве двойной очереди. Вы можете отправлять элементы в любой конец списка с помощью команд LPUSH (слева) и RPUSH (справа). Элементы из любого конца списка можно получить с помощью команд LPOP и RPOP. Вы также можете вернуть набор элементов с помощью команд LRANGE и RRANGE.

В приведенных ниже фрагментах кода показано, как выполнять эти операции с помощью библиотеки StackExchange. Этот код использует BlogPost тип из предыдущих примеров. Как запись блога читается пользователем, IDatabase.ListLeftPushAsync метод отправляет название записи блога в список, связанный с ключом "блог:recent_posts" в кэше Redis.

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:recent_posts";
BlogPost blogPost = ...; // Reference to the blog post that has just been read
await cache.ListLeftPushAsync(
    redisKey, blogPost.Title); // Push the blog post onto the list

По мере того как больше записей блога читаются, их заголовки толкаются в тот же список. Список упорядочен последовательностью, в которой были добавлены заголовки. Последние записи блога слева от списка. (Если одна запись блога читается несколько раз, она будет содержать несколько записей в списке.)

Заголовки последних записей можно отобразить с помощью IDatabase.ListRange метода. Этот метод принимает ключ, содержащий список, начальную точку и конечную точку. Следующий код извлекает заголовки записей блога 10 (элементы от 0 до 9) в левом конце списка:

// Show latest ten posts
foreach (string postTitle in await cache.ListRangeAsync(redisKey, 0, 9))
{
    Console.WriteLine(postTitle);
}

Обратите внимание, что ListRangeAsync метод не удаляет элементы из списка. Для этого можно использовать IDatabase.ListLeftPopAsync методы и IDatabase.ListRightPopAsync методы.

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

await cache.ListTrimAsync(redisKey, 0, 5);

Реализация таблицы лидеров

По умолчанию элементы в наборе не хранятся в определенном порядке. Вы можете создать упорядоченный набор с помощью команды ZADD ( IDatabase.SortedSetAdd метод в библиотеке StackExchange). Элементы упорядочены с помощью числового значения, называемого оценкой, которая предоставляется в качестве параметра для команды.

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

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:post_rankings";
BlogPost blogPost = ...; // Reference to a blog post that has just been rated
await cache.SortedSetAddAsync(redisKey, blogPost.Title, blogPost.Score);

Вы можете получить заголовки и оценки блога в порядке оценки по возрастанию с помощью IDatabase.SortedSetRangeByRankWithScores метода:

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(redisKey))
{
    Console.WriteLine(post);
}

Замечание

Библиотека StackExchange также предоставляет IDatabase.SortedSetRangeByRankAsync метод, который возвращает данные в порядке оценки, но не возвращает оценки.

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

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(
                               redisKey, 0, 9, Order.Descending))
{
    Console.WriteLine(post);
}

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

// Blog posts with scores between 5000 and 100000
foreach (var post in await cache.SortedSetRangeByScoreWithScoresAsync(
                               redisKey, 5000, 100000))
{
    Console.WriteLine(post);
}

Сообщение с помощью каналов

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

Redis предоставляет команду SUBSCRIBE для клиентских приложений, которые используются для подписки на каналы. Эта команда ожидает имя одного или нескольких каналов, на которых приложение будет принимать сообщения. Библиотека StackExchange включает ISubscription интерфейс, который позволяет приложению .NET Framework подписаться и опубликовать их в каналах.

Объект создается ISubscription с помощью GetSubscriber метода подключения к серверу Redis. Затем вы прослушиваете сообщения в канале SubscribeAsync с помощью метода этого объекта. В следующем примере кода показано, как подписаться на канал с именем messages:blogPosts:

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
await subscriber.SubscribeAsync("messages:blogPosts", (channel, message) => Console.WriteLine("Title is: {0}", message));

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

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

Второй параметр — делегат Action. Этот делегат выполняется асинхронно при появлении нового сообщения на канале. В этом примере просто отображается сообщение на консоли (сообщение будет содержать название записи блога).

Для публикации в канале приложение может использовать команду Redis PUBLISH. Библиотека StackExchange предоставляет IServer.PublishAsync метод для выполнения этой операции. В следующем фрагменте кода показано, как опубликовать сообщение в канале message:blogPosts:

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
BlogPost blogPost = ...;
subscriber.PublishAsync("messages:blogPosts", blogPost.Title);

Существует несколько точек, которые необходимо понять о механизме публикации и подписки:

Несколько подписчиков могут подписаться на один канал, и все они получат сообщения, опубликованные в этом канале.
Подписчики получают только сообщения, опубликованные после подписки. Каналы не буферичены, и после публикации сообщения инфраструктура Redis отправляет сообщение каждому подписчику, а затем удаляет его.
По умолчанию сообщения получаются подписчиками в том порядке, в котором они отправляются. В высокоактивной системе с большим количеством сообщений и многими подписчиками и издателями гарантированная последовательная доставка сообщений может замедлить производительность системы. Если каждое сообщение является независимым и порядок не имеет значение, можно включить параллельную обработку системой Redis, что может помочь повысить скорость реагирования. Это можно достичь в клиенте StackExchange, задав параметр PreserveAsyncOrder подключения, используемого подписчиком, значение false:

ConnectionMultiplexer redisHostConnection = ...;
redisHostConnection.PreserveAsyncOrder = false;
ISubscriber subscriber = redisHostConnection.GetSubscriber();

Дальнейшие действия

Следующие шаблоны также могут иметь отношение к вашему сценарию при реализации кэширования в приложениях:

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

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

Руководство по кэшированию

Кэширование в распределенных приложениях

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

Общий кэширование

Рекомендации по использованию кэширования

Решите, когда кэшировать данные

Определение эффективного кэширования данных

Кэшировать динамические данные

Управление истечением срока действия данных в кэше

Недопустимые данные в клиентском кэше

Управление параллелизмом в кэше

Реализация высокой доступности и масштабируемости и повышение производительности

Кэширование и итоговая согласованность

Защита кэшированных данных

Рекомендации по реализации кэширования в Azure

Функции Redis

Redis в качестве базы данных в памяти

Типы данных Redis

Репликация Redis и кластеризация

Использование памяти Redis

Транзакции и пакеты Redis

Безопасность Redis

Кэш Redis Для Azure

Кэширование состояния сеанса и выходных данных HTML

Создание пользовательского кэша Redis

Секционирование кэша Redis

Реализация клиентских приложений кэша Redis

Использование кэширования Redis

Выполнение атомарных и пакетных операций

Выполнение операций с огнем и забыли об операциях кэша

Укажите автоматически истекающий срок действия ключей

Использование тегов для перекрестной корреляции кэшированных элементов

Поиск недавно доступных элементов

Реализация таблицы лидеров

Сообщение с помощью каналов

Рекомендации по сериализации

Дальнейшие действия

Обратная связь

Дополнительные ресурсы

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

Руководство по кэшированию

Кэширование в распределенных приложениях

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

Общий кэширование

Рекомендации по использованию кэширования

Решите, когда кэшировать данные

Определение эффективного кэширования данных

Кэшировать динамические данные

Управление истечением срока действия данных в кэше

Недопустимые данные в клиентском кэше

Управление параллелизмом в кэше

Реализация высокой доступности и масштабируемости и повышение производительности

Кэширование и итоговая согласованность

Защита кэшированных данных

Рекомендации по реализации кэширования в Azure

Функции Redis

Redis в качестве базы данных в памяти

Типы данных Redis

Репликация Redis и кластеризация

Использование памяти Redis

Транзакции и пакеты Redis

Безопасность Redis

Кэш Redis Для Azure

Кэширование состояния сеанса и выходных данных HTML

Создание пользовательского кэша Redis

Секционирование кэша Redis

Реализация клиентских приложений кэша Redis

Использование кэширования Redis

Выполнение атомарных и пакетных операций

Выполнение операций с огнем и забыли об операциях кэша

Укажите автоматически истекающий срок действия ключей

Использование тегов для перекрестной корреляции кэшированных элементов

Поиск недавно доступных элементов

Реализация таблицы лидеров

Сообщение с помощью каналов

Рекомендации по сериализации

Дальнейшие действия

Связанные ресурсы

Обратная связь

Дополнительные ресурсы