Классификация данных (кэширование в Windows Server AppFabric)

Выбор подходящих типов данных для кэширования в приложении позволяет использовать компоненты кэширования Windows Server AppFabric оптимальным образом. Данные могут принимать различные формы и находиться на различных уровнях приложения. Распределенное кэширование упрощает хранение и извлечение различных видов данных, несмотря на границы служб и различия в семантике.

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

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

Тип данных	Шаблон доступа
Ссылки	Совместное чтение
Действие	Монопольная запись
Ресурс	Совместный параллельный доступ на чтение и запись с большим числом транзакций

Эталонные данные

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

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

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

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

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

Данные действий

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

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

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

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

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

Компоненты кэша в AppFabric позволяют создать отдельную область для каждого набора данных. Области поддерживают широкий спектр операций с тегами для работы с наборами данных. Дополнительные сведения см. в разделе Методы на основе тегов (кэширование в Windows Server AppFabric).

AppFabric также позволяет управлять состоянием сеансов в веб-приложениях ASP.NET. Дополнительные сведения см. в разделе Настройка поставщика состояний сеансов ASP.NET (кэширование в Windows Server AppFabric)

Данные ресурсов

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

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

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

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

AppFabric поддерживает как оптимистичный, так и пессимистичный параллелизм. Дополнительные сведения см. в разделе Модели параллелизма (кэширование в Windows Server AppFabric).

См. также

Основные понятия

Схема физической архитектуры кэширования Windows Server AppFabric
Схема логической архитектуры кэширования Windows Server AppFabric

  2011-12-05