Хранилище BLOB-объектов Azure - загрузка файлов по частям - кэширование данных через обратные передачи

Я следил за этим примером для загрузки больших файлов из веб-приложения MVC в Хранилище BLOB-объектов Azure по частям.

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

        var fileToUpload = new CloudFile()
        {
            BlockCount = blocksCount,
            FileName = fileName,
            Size = fileSize,
            BlockBlob = container.GetBlockBlobReference(fileName),
            StartTime = DateTime.Now,
            IsUploadCompleted = false,
            UploadStatusMessage = string.Empty
        };
        Session.Add("CurrentFile", fileToUpload);

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

 CloudFile model = (CloudFile)Session["CurrentFile"];
 model.BlockBlob.PutBlock(*new chunk stream*);

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

Мой вопрос: было бы нормально просто фиксировать и перезаписывать хранилище BLOB-объектов при загрузке каждого фрагмента, а если нет, то есть ли подходящая альтернатива кешированию для приложений Azure?

Если это повлияет на ответ, я бы хотел вызвать контроллер WebAPI из javascript, так что сеанса все равно нет.


azure c# azure-storage-blobs asp.net-web-api azure-caching
person user888734    schedule 08.04.2014    source источник
comment
Будет ли приемлемым решением полностью обойти этот уровень MVC и загрузить файлы прямо в хранилище BLOB-объектов из браузера?   -  person Gaurav Mantri    schedule 09.04.2014
comment
Это для веб-сайта, на который конечные пользователи загружают файлы, поэтому я боюсь, что нет.   -  person user888734    schedule 09.04.2014

Ответы (1)


arrow_upward
0
arrow_downward

У вас есть пара вариантов. Первый - продолжить использование объекта Session и изменить поставщика сеанса (подробнее см. ниже). Второй - напишите свой собственный слой, который будет обрабатывать кеширование для вас, например, Redis. в настоящее время рекомендуемым решением для кеширования в любом случае является Redis.

Для первого варианта есть несколько Доступные поставщики сеансов:

  • Поставщик состояния сеанса памяти - по умолчанию, но, как вы упомянули, плохо масштабируется
  • Поставщик состояния сеанса сервера Sql - это повлияет на производительность, поскольку он будет совершать двусторонние обращения к базе данных SQL.
  • Распределенный в памяти поставщик состояния сеанса, например Redis Cache Session State Provider - В настоящее время это рекомендуемое решение для использования состояния сеанса.

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

Вы можете продолжать использовать объект Session и переключить поставщика сеанса в Web.Config на использование Redis вместо использования в памяти. Сначала добавьте пакет RedisSessionStateProvider из NuGet, затем обновите web.config:

<sessionStatemode="Custom" customProvider="MySessionStateStore">
<providers>
<!--Remove old session state info if currently configured.-->
<add name="MySessionStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider" host="<redis host url/ip here>" accessKey="<your access key here>" />
</providers>

This article on caching guidance in Azure by the Microsoft Patterns and Practices Team has tons of information on both scenarios.

person jsturtevant    schedule 16.02.2016