Кэшированные данные что это

Что такое кэшированные данные или данные кэша?

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

Что такое данные, находящиеся в кэше?

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

В Windows кэшированные данные могут называться просто временными файлами.

Вариант обозначения кэшированных данных в Windows 10

Рассмотрим ситуацию. Вы время от времени посещаете тот или иной сайт. Пусть это будет сайт vk.om. Элементы его дизайна (верхняя синяя полоска, фон, изображения кнопок, ваш аватар и т.д.) меняются довольно редко. Чтобы каждый раз не расходовать ваш интернет – трафик и не тратить время на загрузку этих “статичных” файлов, они помещаются во временное хранилище, которое называется кэш. При очередном заходе на сайт vk.com у вас он загрузится быстрее, так как часть файлов не будет загружаться из интернета, а будет взято из кэша, находящегося на вашем устройстве.

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

Можно ли удалить?

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

В нашем примере с сайтом vk.com это выглядит так: вы заходите на сайт vk.com, регистрируетесь на нем, пользуетесь день, два, понимаете что он вам не интересен и перестаете на него заходить. А данные в кэше ведь остаются. И таких сайтов с течением времени может быть очень много. То же самое касается программ. Ставите интересную программу, пользуетесь ей, затем она вам надоедает, вы ее удаляете, а в кэше могут остаться какие – то ее остатки.

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

Источник

Кэшированные данные: что это такое

30 января 2018 5387

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

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

Очистка кеша на разных устройствах

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

Во вкладках Windows и Applications проставьте/уберите галочки напротив нужных пунктов и нажмите кнопку «Анализ». Сканирование займет некоторое время. Когда утилита найдет весь «мусор», нажмите на кнопку «Очистка».

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

Что значит кэшированные данные на смартфоне и как их почистить

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

Все перечисленные оптимизаторы подойдут только для смартфонов на системе Андроид.

Есть и второй способ удалить данные. Зайдите в настройки телефона и перейдите в раздел «Хранилище» — «Данные кеша» и нажмите «Ок».

Чтобы почистить сохраненную информацию отдельных программ в системных настройках откройте «Все приложения», выберите ПО — Очистить. Или «Все приложения» — «Хранилище» — «Очистить кэш».

На iOS без специальных утилит можно обойтись только если вы хотите очистить браузер Safari. Для этого перейдите в «Настройки» — «Safari» — «Очистить историю и данные». В остальных случаях используйте Battery Doctor — вкладку Junk.

– Опыт работы более 3х лет.
– Специально разработанные проекты.
– Отлаженные процессы.

Источник

Как, почему и когда надо чистить кэш на Android

Кэш приложений может быть спорной темой на Android. Многие люди постоянно чистят кэш приложений, веря в то, что это позволит смартфону работать быстрей. Другие говорят, что это, в первую очередь, сводит на нет всю цель кэширования и просто увеличивает время запуска приложений и выполняемых действий. Истина, как обычно, где-то посередине. Некоторые приложения могут не использовать кэширование эффективно, из-за чего используются излишне большие объемы памяти. Иногда кэш может вызывать проблемы после выхода обновления и надо его сбрасывать. А еще некоторые приложения могут начинать работать медленнее, когда их кэш становится очень большим. Сказать однозначно, надо ли его удалять, нельзя. Но сейчас рассмотрим эту тему подробнее, чтобы вы понимали, когда это делать и как?

Надо ли чистить кэш телефона?

Что такое кэш на Андройд

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

Наш Иван Кузнецов не так давно писал о том, что никогда не чистит кэш и считает это не нужным. Многие из вас, возможно, с ним не согласны. Да я и сам переодически провожу эту процедуру. Тем не менее, для полноты картины можете ознакомиться с его мнением.

Очистка кэша и данных на Android

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

Очистка лишней не будет? Не факт.

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

Как очистить память смартфона. Пять простых шагов.

Когда надо чистить кэш

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

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

Google Play рассылает пустые обновления приложений. Что делать?

Как очистить кэш и данные на Android

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

Шаг 1: Запустите «Настройки» и перейдите в раздел «Хранилище» (или найдите его поиском). Так вы сможете узнать, сколько памяти вашего смартфона занято и чем.

Шаг 2. В разделе «Хранилище» найдите «Приложения» (или «Другие приложения») и выберите его. В нем будут перечислены все приложения, а также то, сколько места каждое из них занимает. В некоторых версиях ОС можно найти сортировку приложений по алфавиту или размеру.

Шаг 3: Зайдите внутрь приложения и удалите кэш или данные. Только надо понимать, что это действие необратимо.

Три простых шага для очистки кэша.

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

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

Надо ли чистить кэш Android-приложений

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

Еще больше полезных советов и рассуждения в нашем Telegram-канале.

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

Чего точно не стоит делать с кэшем, так это чистить его каждый день или каждую неделю. Так вы точно не сделаете лучше никому.

Источник

Обзор кэширования

Кэширование помогает значительно повысить производительность приложений и снизить затраты, независимо от масштаба

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

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

Как работает кэширование?

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

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

Обзор кэширования

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

Области применения. Кэш используется на разных технологических уровнях, включая операционные системы, сетевые уровни, в том числе сети доставки контента (CDN) и DNS, интернет-приложения и базы данных. С помощью кэширования можно значительно сократить задержки и повысить производительность операций ввода-вывода в секунду для многих рабочих нагрузок приложений с большой нагрузкой на чтение, например порталов для вопросов и ответов, игровых ресурсов, порталов для распространения мультимедиа и социальных сетей. Кэшировать можно результаты запросов к базам данных, вычислений, которые требовательны к ресурсам, запросы к API и ответы на них, а также веб-артефакты, например файлы HTML, JavaScript и изображений. Рабочие нагрузки, требующие больших вычислительных мощностей для обработки наборов данных, например сервисы рекомендаций и высокопроизводительное вычислительное моделирование, тоже могут эффективно использовать уровень данных в памяти в качестве кэша. В этих приложениях можно обращаться к очень большим наборам данных в режиме реального времени через кластеры машин, которые охватывают сотни узлов. Управление этими данными в дисковом хранилище является узким местом таких приложений из-за низкой скорости работы базового оборудования.

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

Рекомендации по кэшированию. При реализации уровня кэша необходимо принимать во внимание достоверность кэшируемых данных. Эффективный кэш обеспечивает высокую частоту попаданий, то есть наличия в кэше запрашиваемых данных. Промах кэша происходит, когда запрашиваемых данных в кэше нет. Для удаления из кэша неактуальных данных применяются такие механизмы, как TTL (время жизни). Следует также понимать, требуется ли для среды кэширования высокая доступность. Если она необходима, можно использовать сервисы в памяти, такие как Redis. В ряде случаев уровень в памяти можно использовать как отдельный уровень хранения данных, в отличие от кэширования из основного хранилища. Чтобы решить, подходит ли такой вариант, необходимо определить для данных в сервисе в памяти соответствующие значения RTO (требуемое время восстановления, то есть сколько времени требуется системе на восстановление после сбоя) и RPO (требуемая точка восстановления, то есть последняя восстанавливаемая точка или транзакция). Для соответствия большинству требований RTO и RPO можно применять характеристики и проектные стратегии разных сервисов в памяти.

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

Кэширование с помощью Amazon ElastiCache

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

Преимущества кэширования

Повышение производительности приложений

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

Сокращение затрат на базы данных

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

Снижение нагрузки на серверную часть

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

Прогнозируемая производительность

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

Устранение проблемных мест в базах данных

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

Повышение пропускной способности операций чтения (количество операций ввода-вывода в секунду)

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

Источник

Кэширование

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

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

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

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

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

Частный кэш

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

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

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

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

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

Общий кэш

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

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

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

Общее кэширование имеет два основных недостатка:

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

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

Определение необходимости кэширования данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данные кэша на стороне клиента, утратившие актуальность

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

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

При создании веб-приложения, которое обслуживает данные по протоколу HTTP, можно неявно указать веб-клиенту (браузеру или веб-прокси-серверу) получать самые последние данные. Это можно сделать, если ресурс обновляется путем изменения URI ресурса. Веб-клиенты обычно используют URI ресурса как ключ для кэша на стороне клиента, поэтому при изменении URI веб-клиент игнорирует любые ранее кэшированные версии ресурса и получает вместо них новую версию данных.

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

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

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

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

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

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

Таким образом, приложение должно быть способно определить доступность службы кэширования и переключиться на исходное хранилище данных, если кэш недоступен. Для обработки такой ситуации полезен шаблон «Автоматическое выключение» (Circuit-Breaker Pattern). Служба кэша может быть восстановлена, и как только она станет доступной, кэш может начать заполняться по мере считывания данных из хранилища исходных данных, следуя стратегии шаблона «Отдельно от кэша»(Cache-Aside pattern).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции Redis

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

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

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

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

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

Типы данных Redis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно ограничить доступ к командам путем их отключения или переименования (и предоставив новые имена только привилегированным клиентам).

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

Дополнительные сведения можно найти на странице Безопасность Redis на веб-сайте Redis.

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

Кэш Redis для Azure

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

Портал предоставляет ряд стандартных конфигураций. Минимальное предложение — кэш размером 53 ГБ, который выполняется в виде выделенной службы, поддерживает SSL-подключения (для обеспечения конфиденциальности) и главные или подчиненные репликации с соглашением об уровне обслуживания (доступность 99,9 %). Максимальный вариант — кэш размером 250 МБ без репликации (без гарантии доступности), который выполняется на общем оборудовании.

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

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

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

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

Также можно отслеживать загрузку ЦП, памяти и использования сети для кэша.

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

Кэширование состояния сеанса и результат в формате HTML

если вы создаете ASP.NET веб-приложений, которые выполняются с помощью веб-ролей azure, вы можете сохранить сведения о состоянии сеанса и выходные данные в формате HTML в кэше Azure для Redis. поставщик состояний сеансов для кэша Azure для Redis позволяет обмениваться сведениями о сеансах между разными экземплярами веб-приложения 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 на виртуальной машине CentOS Linux в Azure.

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

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

Секционирование кэша предполагает разделение кэша на несколько компьютеров. Такая структура дает следующие преимущества по сравнению с использованием кэша на одном сервере.

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

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

Подробнее о реализации секционирования с помощью Redis см. на странице Partitioning: how to split data among multiple Redis instances (Секционирование: распределение данных между несколькими экземплярами Redis) на веб-сайте Redis.

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

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

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

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

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

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

Варианты использования кэша Redis

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

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

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

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

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

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

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

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

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

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

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

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

Указание автоматически устаревающих ключей

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

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

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

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

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

Поиск последних использовавшихся элементов

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

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

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

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

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

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

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

Обмен сообщениями с использованием каналов

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

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

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

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

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

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

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

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

Вот некоторые варианты, на которые мы рекомендуем обратить внимание:

Protocol Buffers (protobuf) — это формат, разработанный Google для эффективной сериализации структурированных данных. Он использует строго типизированные файлы определений для определения структур сообщений. Эти файлы определений компилируются в код определенного языка для сериализации и десериализации сообщений. Protobuf можно использовать поверх существующих механизмов RPC или создать с его помощью новую службу RPC.

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

Apache Avro действует примерно так же, как Protocol Buffers Thrift, но без этапа компиляции. Вместо этого во все сериализованные данные добавляется схема с описанием структуры.

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

Для формата двоичной сериализации BSON используется структура, аналогичная JSON. Формат BSON проще, чем JSON, в обработке и просмотре и обеспечивает более высокую скорость сериализации и десериализации. Размер полезных данных примерно такой же, как для JSON. В зависимости от конкретных данных полезные данные BSON могут занять меньше или больше пространства, чем полезные данные JSON. BSON поддерживает несколько дополнительных типов данных, которые недоступны в формате JSON, в частности Date и BinData (для массивов байтов).

MessagePack — это формат двоичной сериализации, который обеспечивает компактность при передаче по сети. В нем не предусмотрены схемы сообщений и проверка их типа.

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

gRPC — это система RPC с открытым исходным кодом, разработанная Google. По умолчанию она использует Protocol Buffers как язык определений и базовый формат обмена сообщениями.

Связанные шаблоны и рекомендации

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

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

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

Источник