Знакомство с сервисом кеширования Windows Azure AppFabric Caching

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

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

Этот сервис был выпущен в виде CTP-версии (Community Technology Preview) к конференции Microsoft Professional Developers Conference в 2010 году и обновлен в феврале 2011 года.

Сервис Caching — важная часть платформы Windows Azure, построенная в соответствии с концепцией Platform as a Service (PaaS). Он основан на той же кодовой базе, что и Windows Server AppFabric Caching.

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

• встроенные провайдеры ASP.NET для кеширования состояния сеанса и вывода страниц, обеспечивающие ускорение работы веб-приложений без модификации их кода;
• кеширование любого управляемого объекта — размер объекта не имеет значения, исключаются издержки сериализации для локального кеширования;
• простая интеграция с существующими приложениями;
• единая модель разработки как для Windows Azure AppFabric, так и для Windows Server AppFabric;
• защищенный доступ и авторизация, поддерживаемые сервисом управления доступом.

Хотя вы можете использовать другие технологии кеширования (например, memcached) как экземпляры в облаке, это закончится тем, что вам придется самостоятельно устанавливать, конфигурировать и администрировать кластеры и экземпляры кеша. А это противоречит главной цели облачной платформы и, в частности, концепции PaaS: избавлению от управления такими деталями. Сервис Windows Server AppFabric Caching снимает с вас это бремя, в то же время ускоряя работу веб-приложений ASP.NET в Windows Azure при минимальных изменениях в коде (или вообще без них) и конфигурации. Как это делается, вы и узнаете из нашей статьи.

За кулисами

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

На высоком уровне он состоит из трех основных частей:

• клиента кеша;
• сервиса кеширования;
• соединения между клиентом и сервисом.

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

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

В случае явного программирования на основе API кеша включите сборку клиента кеша в свое приложение из SDK и вы сможете выдавать GET/PUT-вызовы для сохранения и извлечения данных из кеша. Это хороший вариант для хранения каталога предлагаемых вами игр или других справочных данных для игрового веб-сайта.

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

В кеше можно хранить практически любые объекты: текст, данные, двоичные объекты, CLR-объекты и т. д. Также не накладывается никаких ограничений на размер объекта. Таким образом, что бы вы ни хранили в кеше — объекты в явном виде или состояние сеанса, размер объектов можно не принимать во внимание, решая, стоит ли задействовать сервис Caching в приложении.

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

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

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

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

Как пользователь вы получаете возможность взаимодействовать с защищенной конечной точкой WCF (Windows Communication Foundation), объем памяти, нужный вашему приложению, и API для клиента кеша, через который вы будете сохранять и извлекать данные. Главное здесь память. Если вы запрашиваете 1 Гб памяти кеша, то и получаете этот объем для хранения своих объектов — в отличие от объема памяти, доступного в экземпляре Windows Azure, за который вы платите. Сервис Caching выделяет вам запрошенный объем памяти из пула распределенного кластера машин, которыми он управляет. В итоге вы получаете возможность автоматического расширения или сокращения кеша в зависимости от потребностей, и для этого достаточно внести простое изменение в конфигурацию. В этом смысле сервис Caching можно рассматривать как виртуальный пул разбитой на разделы общей памяти, обеспечивающий высокую гибкость.

Еще одна вещь заключается в том, что сервис Caching автоматически разбивает ваш кеш на разделы, чтобы вы не потеряли данные в случае выхода из строя какой-либо машины, даже если вы не покупали более дорогостоящий вариант кеша с высокой доступностью (high availability, HA). (Вариант HA в настоящее время недоступен в Windows Azure AppFabric Caching — его можно использовать только в Windows Server AppFabric Caching.) Эта схема разбиения на разделы автоматически увеличивает производительность и уменьшает вероятность потери данных; при этом от вас не требуется знать, как работает нижележащий сервис.

Третья и последняя часть — соединение между вашим клиентом кеша и сервисом Caching. Взаимодействие между клиентом кеша и сервисом осуществляется с помощью WCF, и модель программирования WCF абстрагируется от разработчика: клиент кеша транслирует GET/PUT-вызовы в соответствии с WCF-протоколом, понятным сервису. Вам нужно знать лишь то, что этот коммуникационный канал защищен, что крайне важно, особенно в облаке. Защита кеша осуществляется с помощью маркера сервиса управления доступом (Access Control Service, ACS), который вы получаете при создании именованного кеша. Сервис Caching использует этот маркер для ограничения доступа к данным, кешированным вашим клиентом.

Руководство по архитектуре

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

Рис. 1. Использование памяти, сети и дисковой подсистемы в сценариях с манипуляциями над данными

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

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

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

Какие данные следует помещать в кеш? Ответ сильно зависит от общего дизайна вашего приложения. Когда мы говорим о данных в сценариях с кешированием, мы обычно разбиваем их на типы данных и шаблоны доступа, как показано в табл. 1 (более глубокое объяснение этих шаблонов доступа к данным см. по ссылке msdn.microsoft.com/library/ee790832).

Табл. 2. Данные в сценариях с применением кеширования

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

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

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

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

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

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

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

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

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

Настройка сервиса AppFabric Caching

Чтобы начать работу с сервисом Windows Azure AppFabric Caching, перейдите на portal.appfabriclabs.com. Это CTP-портал, где мы можете ознакомиться с сервисом Caching. Пользоваться им можно бесплатно, но никаких соглашений по уровню обслуживания не предоставляется.

На портале выберите Cache, а затем создайте новый кеш, щелкнув New Namespace. Диалоговое окно для настройки пространства имен сервиса кеша показано на рис. 2.

Рис. 3. Конфигурирование пространства имен сервиса кеша

Вам нужно указать лишь два параметра: уникальное пространство имен сервиса и размер кеша (в CTP-версии можно выбирать между 128 Мб и 256 Мб). Щелкните кнопку OK, и сервис начнет собирать для вас кеш в фоновом режиме. Обычно это занимает от 10 до 15 секунд. По окончании операции вы получаете полнофункциональный, распределенный кеш, доступный вашим приложениям.

После создания вы можете посмотреть свойства кеша (рис. 4). (Заметьте, что мы затерли некоторую информацию, специфичную для учетной записи.)

Рис. 4. Свойства сервиса кеша

Как видите, мы создали кеш, использующий пространство имен CachingDemo. Здесь есть еще пара элементов важных данных, которые будут позднее задействованы в нашем коде: Service URL и Authentication Token. Service URL — это конечная точка TCP, к которой будет подключаться приложение при взаимодействии с сервисом Caching. Authentication Token является зашифрованным маркером, который будет передаваться в сервис управления доступом для аутентификации вашего сервиса.

Кеширование в вашем приложении

Теперь, прежде чем приступить к кодированию, скачайте Windows Azure AppFabric SDK. Вы получите его по ссылке go.microsoft.com/fwlink/?LinkID=184288 или щелчком ссылки на портале.

Убедитесь, что на вашем компьютере еще не установлен Windows Server AppFabric Cache. Хотя API симметричен, текущие сборки несовместимы. Windows Server AppFabric Cache регистрирует свои сборки Caching в кеше глобальных сборок (Global Assembly Cache, GAC), из-за чего ваше приложение загрузит не те сборки. Эта проблема будет устранена к тому времени, когда сервис Windows Azure AppFabric Caching выйдет на производственный режим работы, а пока между ними возникают некоторые трения.

Сначала создадим простое консольное приложение на C#. После создания обновите проект, чтобы он был рассчитан на полноценную Microsoft .NET Framework, а не на Client Profile. Кроме того, вам понадобится добавить сборки Caching, которые обычно размещаются в каталоге C:\Program Files\Windows Azure AppFabric SDK\V2.0\Assemblies\Cache. Пока добавьте следующие две сборки:

• Microsoft.ApplicationServer.Caching.Client;
• Microsoft.ApplicationServer.Caching.Core.

Одно изменение между октябрьской CTP-версией и февральским обновлением заключается в том, что теперь вы должны использовать System.Security.SecureString для своего маркера аутентификации. Цель SecureString — не дать вам поместить свой пароль или маркер в память, выделенную вашему приложению, и тем самым повысить степень его защищенности. Однако, чтобы это работало в простом консольном приложении, вы должны создать следующий метод:

static private SecureString Secure(string token) {
  SecureString secureString = new SecureString();
  foreach (char c in token) {
    secureString.AppendChar(c);
  }
  secureString.MakeReadOnly();
  return secureString;
}

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

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

Рис. 5. Загрузка кеша по умолчанию

private static DataCache configureDataCache(
  SecureString authorizationToken, string serviceUrl) {

  // Declare an array for the cache host
  List<DataCacheServerEndpoint> server =
    new List<DataCacheServerEndpoint>();
  server.Add(new DataCacheServerEndpoint(serviceUrl, 22233));

  // Set up the DataCacheFactory configuration
  DataCacheFactoryConfiguration conf =
    new DataCacheFactoryConfiguration();
  conf.SecurityProperties =
    new DataCacheSecurity(authorizationToken);
  conf.Servers = server;

  // Create the DataCacheFactory based on config settings
  DataCacheFactory dataCacheFactory =
    new DataCacheFactory(conf);

  // Get the default cache client
  DataCache dataCache = dataCacheFactory.GetDefaultCache();

  // Return the default cache
  return dataCache;
}

Мы определили новый DataCacheServerEndpoint на основе URL сервиса (который мы будем предоставлять), указывающий на порт 22233. Затем мы создали DataCacheFactoryConfiguration, передали наш маркер аутентификации (SecureString) и присвоили его свойствам, связанным с защитой, — это позволит нам аутентифицироваться в сервисе. Далее мы просто конструируем DataCacheFactory, получаем DataCache на основе кеша по умолчанию и возвращаем кеш по умолчанию.

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

А теперь собираем все это в методе Main нашего приложения (рис. 5).

Рис. 6. Метод Main консольного приложения

static void Main(string[] args) {
  // Hardcode your token and service url
  SecureString authorizationToken =
    createSecureString("YOURTOKEN");
  string serviceUrl = "YOURCACHE.cache.appfabriclabs.com";

  // Create and return the data cache
  DataCache dataCache =
    configureDataCache(authorizationToken, serviceUrl);

  // Enter a value to store in the cache
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();

  // Put your value in the cache
  dataCache.Put("key", value);

  // Get your value out of the cache
  string response = (string)dataCache.Get("key");

  // Write the value
  Console.WriteLine("Your value: " + response);
}

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

Включение маркеров и URL сервиса в код годится только для примера. Портал предоставляет XML, который можно вставлять в файл app.config (или web.config), и тогда API будет управлять всем этим за вас.

На портале выберите свой кеш и щелкните кнопку View Client Configuration. Это приведет к открытию диалога, где содержится XML для конфигурации. Скопируйте XML и вставьте его в свой конфигурационный файл. В итоге кнопки должны выглядеть, как показано на рис. 7.

Рис. 7. Конфигурация клиента

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section
      name="dataCacheClient"
      type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core"
      allowLocation="true"
      allowDefinition="Everywhere"/>
  </configSections>
  <dataCacheClient deployment="Simple">
    <hosts>
      <host
        name="YOURCACHE.cache.appfabriclabs.com"
        cachePort="22233" />
    </hosts>
    <securityProperties mode="Message">
      <messageSecurity
          authorizationInfo="YOURTOKEN">
      </messageSecurity>
    </securityProperties>
  </dataCacheClient>
</configuration>

Теперь мы можем основательно переработать код, избавившись от методов createSecureString и configureDataCache, и остаться с таким кодом:

static void Main(string[] args) {
  DataCacheFactory dataCacheFactory =
    new DataCacheFactory();
  DataCache dataCache = dataCacheFactory.GetDefaultCache();
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();
  dataCache.Put("key", value);
  string response = (string)dataCache.Get("key");
  Console.WriteLine("Your value: " + response);
}

Здесь мы всего лишь создаем новый экземпляр DataCacheFactory, и все конфигурационные параметры в файле app.config считываются в него по умолчанию.

Как уже было показано, вы можете использовать API напрямую или управлять DataCacheFactory в своей конфигурации. Хотя мы выполняли лишь операции PUT и GET над простыми данными, мы могли бы легко хранить данные, полученные от SQL Azure, Windows Azure или другого провайдера данных. Более сложный пример использования кеша для справочных данных, хранящихся в SQL Azure см. в «Caching Service Hands-On Lab» из «Windows Azure Platform Training Course» (msdn.microsoft.com/gg457894).

Хранение данных сеанса

Теперь рассмотрим, как использовать сервис Caching для хранения данных сеанса для нашего веб-приложения ASP.NET. Это эффективный вариант, так как он позволяет отделить состояние сеанса от внутрипроцессной памяти каждого из наших веб-клиентов, упрощая тем самым масштабирование наших приложений далеко за рамки одного экземпляра в Windows Azure.

Это важно для сервисов, которые не поддерживают закрепленные сеансы (sticky sessions), например Windows Azure. Нет никаких гарантий, что пользователь будет направляться в тот же экземпляр при очередном запросе; средство балансировки нагрузки в Windows Azure явным образом использует принцип карусели, поэтому вероятнее всего новый запрос от вашего пользователя будет направлен в новый экземпляр. При использовании сервиса Caching для хранения состояния сеанса не имеет значения, в какой экземпляр направлен запрос пользователя, так как все экземпляры поддерживаются одним и тем же провайдером состояний сеансов.

Для начала создайте новый проект Windows Azure и добавьте ASP.NET Web Role. В веб-роль добавьте все сборки, предоставляемые Windows Azure AppFabric SDK, в том числе:

• Microsoft.ApplicationService.Caching.Client;
• Microsoft.ApplicationService.Caching.Core;
• Microsoft.Web.DistributedCache;
• Microsoft.WindowsFabric.Common;
• Microsoft.WindowsFabric.Data.Common.

Затем обновите свой файл web.config так, чтобы за элементом <configuration> первым делом следовали элементы <configSections> и <dataCacheClient> (если они окажутся не первыми, вы получите ошибки).

Ключом к использованию сервиса Caching для работы с состоянием сеанса является сборка Microsoft.Web.DistributedCache. Она содержит собственный провайдер состояний сеансов, использующий сервис Caching.. Вернитесь на портал LABS, где вы брали XML для своих конфигурационных файлов, и найдите элемент <sessionState> — вы можете поместить его прямо в элемент <system.web> в вашем файле web.config, и он немедленно сообщит приложению начать использовать сервис Caching для работы с состоянием сеанса:

<system.web>
  <sessionState mode="Custom"
    customProvider="AppFabricCacheSessionStoreProvider">
    <providers>
      <add name="AppFabricCacheSessionStoreProvider"
        type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
        cacheName="default"
        useBlobMode="false" />
    </providers>
  </sessionState>
  ...
</system.web>

Чтобы проверить, работает ли это, откройте файл Global.asax.cs и добавьте в метод Session_Start следующий код:

void Session_Start(object sender, EventArgs e) {
  int i = 0;
  while (i < 10) {
    Session.Add(Guid.NewGuid().ToString(), DateTime.Now.ToString());
    i++;
  }
}

Этот код добавит в контекст сеанса 10 случайных элементов. Затем откройте страницу Default.aspx.cs и обновите метод Page_Load:

protected void Page_Load(object sender, EventArgs e) {
  foreach (var key in Session.Contents) {
    Response.Write("key: " + key + ", guid: " +
      Session[key.ToString()].ToString()  + "<br/>");
  }
}

Этот метод запишет все добавленные значения в контекст сеанса. Наконец, откройте файл ServiceConfiguration.cscfg и увеличьте счетчик экземпляров с 1 до 2:

<Instances count="2" />

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

Что дальше?

Запуск сервиса Windows Azure AppFabric Caching в качестве коммерческого запланирован на первую половину 2011 г. В первом коммерческом выпуске ряд средств, имеющихся в Windows Server AppFabric, будет пока недоступен. Некоторые из исключений сделаны преднамеренно, так как они могут оказаться неприменимыми в облаке. Однако такие средства, как уведомления, вполне релевантны в Windows Azure и крайне важны в сценариях с применением локального кеша, поэтому их появление запланировано на краткосрочную перспективу. Аналогично возможность включения HA для данного именованного кеша также находится в списке приоритетов.

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

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

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