Построение гибридных приложений в облаке на платформе Windows Azure patterns & practices



Pdf просмотр
страница30/33
Дата28.11.2016
Размер8.44 Mb.
Просмотров6314
Скачиваний0
1   ...   25   26   27   28   29   30   31   32   33
Пессимистичный, с блокированием.
Оптимистичный подход используется в основном тогда, когда шансы конфликта невелики, и, хотя он прост в теории, его реализация неизбежно предполагает определенную степень сложности для обработки возможных условий состязания, которые могут возникнуть.
Пессимистичный подход построен на противоположной точке зрения. Предполагается, что несколько экземпляров веб-приложения попытаются одновременно изменить одни и те же данные, поэтому данные блокируются во время извлечения из кэша, чтобы предотвратить проблему обновления. Когда обновленный объект возвращается в кэш, блокировка снимается.
Если веб-приложение пытается получить и заблокировать объект, который уже заблокирован другим экземпляром приложения, то оно получит отказ (объект заблокирован не будет). По истечении короткого периода времени это веб-приложение сможет снова попробовать получить и заблокировать объект. Хотя такой подход и гарантирует согласованность кэшированных данных, в идеале любые операции обновления должны быть очень быстрыми и соответствующие блокировки должны происходить в очень короткий срок, чтобы минимизировать возможность столкновения и не заставлять веб-приложения ожидать в течение длительного периода, так как это может повлиять на время отклика и пропускную способность приложения.
Мнение Маркуса
Приложение задает продолжительность блокировки при получении данных. Если приложение не снимает блокировку в течение этого периода, то блокировка снимается службой Windows Azure Caching. Эта функция предназначена для предотвращения ситуации, когда в приложении возникает постоянная ошибка блокировки данных. Вы должны установить такой период, который обеспечит вашему приложению достаточное время для выполнения операции обновления, но этот период должен быть не настолько долгим, чтобы заставлять другие экземпляры ожидать доступа к этим данным в течение слишком долгого времени.
Если вы размещаете несколько экземпляров службы Windows Azure Caching в разных центрах обработки данных, то проблема обновления становится еще более острой, так как, возможно, придется синхронизировать кэш не только с надежным источником данных, но и с другими кэшами, расположенными в разных местах. Синхронизация обязательно порождает сетевой трафик, на который в свою очередь влияют задержки, а иногда и ненадежность Интернета. В большинстве случаев предпочтительнее непосредственно обновлять данные надежного источника данных, удалять данные из кэша в том же центре обработки данных, в котором находится веб-приложение, и ждать естественного истечения срока хранения кэшированных данных в каждом центре обработки данных, когда можно будет заполнить кэш повторно из надежного источника данных.
Логика, по которой обновляется надежный источник данных, должна минимизировать вероятность перезаписи изменения, сделанного другим экземпляром приложения, возможно, включая сведения о версии в данные и проверку того, что при выполнении обновления номер версии не изменился.
Целью удаления данных из кэша, а не простого их обновления, является снижение вероятности потери изменений, сделанных другими экземплярами веб-приложения в других местах, а также сведение к минимуму шансов возникновения несоответствий, в случае неудачного обновления надежного хранилища данных. В следующий раз, когда эти данные потребуется, соответствующая версия данных будет считываться из надежного хранилища данных и копироваться в кэш.

345
Если необходимо незамедлительное обновление в различных местах хранения данных, то вы можете реализовать пользовательское решение с помощью топиков шины интеграции, реализовывая варианты шаблонов, описанные в разделе «Репликация и синхронизация данных с помощью топиков и подписок шины интеграции» в «Приложении A. Репликация, распространение и синхронизация данных».
Оба подхода иллюстрируются ниже в этом приложении, в разделе «Рекомендации по использованию кэширования Azure».
Мнение Джаны
Включение службы Windows Azure Caching в веб-приложение должно быть осознанным этапом проектирования, так как это напрямую влияет на обновление логики приложения.
В какой-то степени вы можете скрыть эту сложность и способствовать повторному использованию путем создания уровня кэширования в виде библиотеки и абстрагирования кода, который извлекает и обновляет кэшированные данные, но все равно эта логика должна быть где-то реализована.
Особенностью службы Windows Azure Caching является то, что необходимо включить в веб-приложения комплексную обработку исключений и логику восстановления. Пример:

Условие состязания существует в простой реализации ориентированного на кэш шаблона, который позволяет двум экземплярам веб-приложения пытаться добавлять одинаковые данные в кэш. В зависимости от способа реализации логики, которая хранит данные в кэше, она может привести к тому, что один экземпляр перезапишет данные, которые были ранее добавлены другим экземпляром (если вы используете метод кэша Put), или она может привести к сбою экземпляра с исключением DataCacheException (если вы используете метод кэша Add). Дополнительная информация представлена в статье «Add an Object to a Cache» на сайте http://msdn.microsoft.com/en-us/library/ee790846.aspx

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

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

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

346
В дальнейшем приложение ссылается на объект из локального кэша. Конечно же, если объект не найден в общем кэше, приложение должно извлечь объект из надежного источника данных.
После того как элемент кэширован локально, локальная версия этого элемента будет использоваться до истечения срока его хранения или удаления из кэша. Однако вполне возможно, что другое приложение может изменить данные в общем кэше. В этом случае приложение, которое использует локальный кэш, не увидит этих изменений до тех пор, пока локальная версия элемента не будет удалена из локального кэша. Поэтому, несмотря на то что использование локального кэша может значительно улучшить время отклика для приложения, локальный кэш может очень быстро стать несогласованным, если информация в общем кэше изменяется. По этой причине вы должны настроить локальный кэш для хранения объектов только в течение короткого периода времени до их обновления. Если данные, содержащиеся в общем кэше, очень динамичны и важна их согласованность, то отдается предпочтение использованию общего кэша, а не локального.
После того как элемент скопирован в локальный кэш, приложение может получить доступ к нему с помощью тех же интерфейсов API службы Windows Azure Caching и программной модели, которые работают в общем кэше. Взаимодействие с локальным кэшем полностью прозрачно. Например, если приложение изменяет элемент и помещает обновленную запись обратно в кэш, интерфейсы API службы
Windows Azure Caching обновляют локальный кэш и копию в общем кэше.
На локальный кэш не распространяются те же квоты ресурсов, что для общего кэша, управляемого службой Windows Azure Caching. Можно указать максимальное число объектов, которые могут содержаться в кэше при его создании, а хранилище для кэша выделяется непосредственно из памяти, доступной для приложения.
Мнение Маркуса
Вы включаете локальное кэширование путем заполнения члена LocalCacheProperties объекта
DataCacheFactoryConfiguration, который используется для управления настройками клиента кэша. Вы можете выполнить эту задачу программно или декларативно в конфигурационном файле приложения. Можно указать размер кэша и период хранения кэшированных элементов по умолчанию. Дополнительная информация представлена в статье «Enable
Windows Server AppFabric Local Cache (XML)» на сайте http://msdn.microsoft.com/en- us/library/ee790880.aspx
Кэширование состояния сеанса веб-приложения
Для веб-приложений и служб ASP.NET служба Windows Azure Caching позволяет использовать поставщика состояния сеанса DistributedCacheSessionStateStoreProvider. С этим поставщиком вы можете хранить состояние сеанса в кэше Windows Azure. Использование кэша Windows Azure для хранения состояния сеанса предоставляет ряд преимуществ:

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

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

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

347 в статье «How to: Configure the ASP.NET Session State Provider for Windows Azure Caching» на сайте http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx
После настройки поставщика, вы можете получить к нему программный доступ через объект Session, используя тот же код, как и обычное веб-приложение ASP.NET; вам не нужно вызывать API службы
Windows Azure Caching.
Кэширование выводимых данных в формате HTML
Класс DistributedCacheOutputCacheProvider, доступный для службы Windows Azure Caching, реализует кэширование выводимых данных для веб-приложений. С помощью этого поставщика, вы можете создавать масштабируемые веб-приложения, которые используют преимущества службы Windows
Azure Caching для кэширования HTTP-ответов, которые они создают для веб-страниц, возвращаемых в клиентские приложения, а также этот кэш может использоваться несколькими экземплярами приложения. Этот поставщик имеет несколько преимуществ по сравнению с обычным кэшем выводимых данных процесса, в том числе:

Можно кэшировать большие объемы выводимых данных.

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

Он позволяет использовать сжатие для сохранения памяти и пропускной способности.
Опять же, вы можете генерировать данные для настройки этого поставщика с помощью портала управления и копировать эту информацию непосредственно в конфигурационный файл приложения.
Дополнительная информация представлена в статье «How to: Configure the ASP.NET Output Cache
Provider for Windows Azure Caching» на сайте http://msdn.microsoft.com/en- us/library/windowsazure/gg185676.aspx
Как и класс DistributedCacheSessionStateStoreProvider, класс DistributedCacheOutputCacheProvider
является полностью прозрачным. Если ваше приложение ранее использовало кэширование выводимых данных, вам не придется делать изменения в коде.
Рекомендации по использованию службы Windows Azure Caching
Ниже описано несколько наиболее распространенных сценариев использования службы Windows Azure
Caching:

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

348
Мнение Маркуса
Чтобы использовать службу Windows Azure Caching наилучшим образом, кэшируйте только данные, которые редко меняются.
На рисунке 5 показана возможная структура такого решения. В этом примере ряду веб- приложений, реализованных в виде веб-ролей, которые размещены в разных центрах обработки данных, требуется доступ к адресам клиентов, содержащимся в базе данных SQL
Server, которая расположена локально в организации. Для сокращения сетевой задержки, связанной с повторяемыми запросами к тем же данным через Интернет, информация, используемая веб-приложениями, кэшируется с помощью службы Windows Azure Caching.
Каждый центр обработки данных содержит отдельный экземпляр службы кэширования, а веб- приложения имеют доступ только к кэшу, который находится в том же центре обработки данных. Веб-приложения запрашивают только адреса клиентов, хотя другие приложения, работающие локально, иногда могут вносить изменения. Период хранения для каждого элемента в кэше равен 24 часам, поэтому любые изменения, внесенные в эти данные, в итоге будут видны веб-приложениям.
Рисунок 5
Кэширование статических данных для сокращения сетевых задержек в веб-
приложениях

Веб-приложения и службы, работающие в облаке, требуют быстрого доступа к общим
данным и могут часто изменять эти данные.
Этот сценарий является потенциально сложным расширением предыдущего случая в зависимости от расположения данных, частоты обновлений, распределения веб-приложений
Локальная инфраструктура
Веб-роль
Центр обработки
данных A
Срок хранения кэшированных данных истекает через 24 часа, и они обновляются из базы данных клиентов с помощью веб-ролей
Windows Azure
Веб-роли Windows
Azure заполняют кэш и получают доступ к нему в том же центре обработки данных
Веб-роли Windows
Azure запрашивают только данные клиентов
Приложения, работающие локально, иногда могут менять данные клиентов
Веб-роль
Веб-роль
Веб-роль
База данных клиентов
Кэш Windows
Azure
Центр обработки
данных Б
Кэш Windows
Azure

349 и служб, а также срочности, с которой обновления должны быть видны этим веб-приложениям и службам.
В самом простом случае, когда веб-приложению необходимо обновить объект, оно извлекает элемент из кэша (делая выборку из надежного хранилища данных, если это необходимо), изменяет этот элемент в кэше и вносит соответствующие изменения в надежное хранилище данных. Однако этот процесс состоит из двух этапов, а чтобы свести к минимуму шансы возникновения условий состязания, все обновления должны выполняться в том же порядке, в котором выполняются эти этапы. В зависимости от вероятности конфликтующего обновления, выполняемого активным экземпляром приложения, вы можете реализовать либо оптимистичную, либо пессимистичную стратегию обновления кэша, как описано ранее в разделе «Обновление кэшированных данных». Этот процесс показан на рисунке 6. В этом примере локальная база данных клиентов является надежным хранилищем данных.
Рисунок 6
Обновление данных в кэше и надежном хранилище данных
Описанный подход годится для решения, которое разворачивается в одном центре обработки данных. Однако, если ваши веб-приложения и службы размещены в нескольких местах, то следует реализовать кэш в каждом центре обработки данных. В таком случае обновления должны быть тщательно синхронизированы и скоординированы для всех центров обработки данных, а все копии кэшированных данных должны быть изменены. Как описано в разделе
«Обновление кэшированных данных», у вас есть, по крайней мере, два варианта для решения этой проблемы:
◦ Обновите только надежное хранилище данных и удалите элемент из кэша в центре обработки данных, в котором размещено веб-приложение. В итоге срок хранения кэшированных данных в любом другом центре обработки данных закончится, и они
Локальная инфраструктура
База данных клиентов
Кэш Windows
Azure
Веб-приложение копирует данные клиентов в кэш
Windows Azure
Веб-приложение обновляет данные клиентов в кэше
Windows Azure
Веб-приложение извлекает данные клиентов из надежного хранилища
Веб-приложение обновляет данные клиентов в надежном хранилище
Центр
обработки данных

350 будут удалены из кэша. В следующий раз, когда эти данные потребуются, они будут получены из надежного хранилища и использованы для повторного заполнения кэша.
◦ Реализуйте собственное решение, используя топики шин интеграции, как описано в разделе «Репликация и синхронизация данных с помощью топиков и подписок шины интеграции» в пособии
«Приложение A. Репликация, распространение и синхронизация данных»
Первый вариант явно проще, чем второй, но в течение некоторого времени различные кэши могут быть несогласованны друг с другом и надежным источником данных, в зависимости от периода хранения, который применяется к кэшированным данным. Кроме того, веб- приложения и службы могут использовать локальную базу данных SQL Azure вместо получения доступа к локальной версии SQL Server. Эти базы данных SQL Azure могут быть реплицированы и синхронизированы в каждом центре обработки данных, как описано в разделе
«Приложение
A. Репликация, распространение и синхронизация данных»
. Применение этой стратегии способствует снижению сетевых задержек, связанных с извлечением данных во время заполнения кэша, за счет еще большей сложности, если веб-приложения изменяют эти данные.
Они обновляют локальную базу данных SQL Azure, и эти обновления должны быть синхронизированы с базами данных SQL Azure в других центрах обработки данных.
В зависимости от того, насколько часто происходит эта синхронизация, кэшированные данные в других центрах обработки данных могут быть устаревшими на протяжении значительного периода времени. Для кэшированных данных не только должен истекать срок хранения, они также должны ждать осуществления синхронизации базы данных. В этом случае настройка интервала между событиями синхронизации базы данных, а также установка срока хранения кэшированных данных имеют важное значение, если веб-приложение должно свести до минимума промежуток времени, когда оно готово обрабатывать устаревшую информацию.
На рисунке 7 показан пример такого решения с реплицированными экземплярами SQL Azure, выступающими в качестве надежного хранилища данных.
Рисунок 7
Распространение обновлений между кэшами Windows Azure и реплицированными
хранилищами данных
База данных клиентов
База данных клиентов
Кэш Windows
Azure
Веб-приложение заполняет кэш из локальной базы данных клиентов
Когда срок хранения элемента кэша истекает, он обновляется с помощью веб- приложения из локальной базы данных клиентов
Двунаправленная репликация синхронизирует базы данных SQL Azure
Обновление записей клиентов применяются к базе данных клиентов / соответствующий элемент удаляется из кэша; он извлекается и кэшируются в следующий раз, когда требуется эта информация
Центр
обработки данных A
Кэш Windows
Azure
Центр
обработки данных Б

351
Реализация пользовательского решения, основанная на топиках и подписках шины интеграции, является более сложной, но в результате обновления синхронизируются быстрее в центрах обработки данных. На рисунке 8 показан один из возможных вариантов реализации данного подхода. В этом примере веб-приложение получает и кэширует данные в кэше Windows Azure, размещенном в том же центре обработки данных. Выполнение обновления данных предполагает следующую последовательность задач: a.
Веб-приложение обновляет надежное хранилище данных (локальная база данных). b.
Если обновление базы данных было успешным, то веб-приложение дублирует это изменение в данные, которые хранятся в кэше в том же центре обработки данных. c.
Веб-приложение посылает сообщение об обновлении в топик шины интеграции. d.
Приложения-получатели, работающие в каждом центре обработки данных, подписываются на этот топик и получают сообщения об обновлениях. e.
Если в настоящее время данные кэшируются локально, то приложение- получатель записывает обновление в кэш этого центра обработки данных.
Примечание
Если на данный момент данные не кэшированы в этом центре обработки данных, то можно просто удалить сообщение об обновлении.
Получатель в центре обработки данных, размещающий веб-приложение, которое инициировало обновление, также получит сообщение об обновлении. Вы можете включать дополнительные метаданные в сообщение об обновлении с подробностями экземпляра веб-приложения, которое посылает сообщение. Впоследствии, чтобы предотвратить обновление кэша без необходимости (например, когда экземпляр веб- приложения, который послал сообщение, такой же, как и текущий экземпляр), получатель может включить соответствующую логику.
Обратите внимание, что в этом примере надежный источник данных расположен локально, но для использования реплицированных экземпляров SQL Azure в каждом центре обработки данных эта модель может быть расширена. В этом случае каждое приложение-получатель обновляет локальный экземпляр SQL Azure, а также вносит изменения в данные в кэше.

352
Рисунок 8
Распространение обновлений между кэшами Windows Azure и надежным
хранилищем данных
Примечание
Возможен также вариант, что постоянного хранилища данных не существует, и в этом случае кэши выступают в качестве надежного хранилища. Примером этого сценария могут быть сетевые игры, в которых текущий счет игры постоянно обновляется, но он должен быть доступен для всех экземпляров игрового приложения. В этом случае кэш в каждом центре обработки данных содержит копию всех данных, но все равно может применяться такое же общее решение без локальной базы данных, которое изображено на рисунке 8.
Веб- приложение
Получатель получает сообщение об «обновлении» и вносит изменения в кэш
Веб- приложение
Локальная
инфраструктура
Топик
шины
интег-
рации
Чтобы изменить данные, веб- приложение обновляет базу данных и кэш, а затем отправляет сообщение об
«обновлении» в тему шины интеграции
Фильтры передают все сообщения об
«обновлении» в обе подписки
Веб-приложение заполняет и использует кэш
Кэш Windows
Azure
Кэш Windows
Azure
Сообщение об обновлении
Обновление
1
Обновление 1
Обновление
2
Обновление 2

Каталог: download
download -> Составление простейшей программы в среде lego education. Запуск модели «Обезьянка барабанщица», «Рычащий лев», «Автомобиль»
download -> Функциональные части компьютера, история развития, базовая конфигурация
download -> Компьютер: друг или враг?
download -> Лекция №2 «Теоретические основы игры дошкольника» Зарубежные и отечественные теории игры
download -> Доклад муниципальное образовательное
download -> Литература для воспитанников стр. Приложения стр
download -> Министерство здравоохранения Республики Беларусь
download -> Игра как средство активизации познавательной активности учащихся в ходе изучения темы Алгоритмизация и программирование


Поделитесь с Вашими друзьями:
1   ...   25   26   27   28   29   30   31   32   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал