Синхронизировать файлы из BLOB-объекта Azure на локальный

Question

Мне нравится писать процесс в рабочей роли, загружать (синхронизировать) пакет файлов из папки (каталога) в локальную зеркальную папку (каталог)

Есть ли временная метка (или способ получить) во время последнего обновления папки (каталога)?

Поскольку структура папки (каталога) не определена, а проще говоря, это загрузить все, что там, в локальную, как только она изменится .Кроме рекурсии и установки таймера для повторной проверки, у вас есть еще одна умная идея?

(правка) ps Я нашел много решений по синхронизации файлов из локального хранилища в Azure, но тот же принцип для локальных файлов не можетприменить к BLOB-объектам Azure. Я по-прежнему ищу способ, с помощью которого можно было бы проще всего загружать (синхронизировать) файлы на локальный компьютер сразу после их изменения.

Answer 1

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

Рассмотрим следующий сценарий:

1. Храните ваши представления в хранилище BLOB-объектов.
2. Реализация кэша Azure (AppFabric).
3. Сохраните любой файл представления в кэш, если он еще не существует в веб-запросе с неограниченным (или очень длительным) сроком действия.
4. Включить локальный кеш в экземплярах веб-роли с коротким сроком действия (например, 5 минут)
5. Создайте (отдельную, отдельную) рабочую роль вне ваших веб-ролей, которая сканирует ETag ваших BLOB-объектов на предмет изменений в интервале. Сброс ключа кэша представления для любого большого двоичного объекта изменилось
6. Избавьтесь от этих уродливых "рабочих" внутри ваших веб-ролей: -)

В этом сценарии есть над чем подумать:

• Ваши обновленные представления будут попадать в экземпляры веб-ролей в течение «времени истечения срока действия локального кэша + интервал проверки работника». Чем ниже значения, тем больше распределенных запросов кеша и транзакций с хранилищем BLOB-объектов.
• Azure AppFabric Cache - это единственная служба Azure, которая не позволяет всей платформе быть действительно масштабируемой. Вы должны выбрать лучший план кэширования на основе общего размера (в МБ) ваших представлений, количества ваших экземпляров и количества одновременных запросов кэша, требуемых для каждого экземпляра.
• рассмотрите возможность кэширования скомпилированных представлений внутри ваших экземпляров (не в кэше AppFabric). Сброс этого локального кэша на основе выделенного ключа / ключей кэша AppFabric. Это значительно повысит производительность, поскольку рендеринг выходного html будет так же прост, как введение модели в предварительно скомпилированные представления.
• конечно, код для извлечения из кэша в ваших веб-ролях должен иметь возможность извлекать представление из первичного источника (хранилища), если по какой-либо причине он не может извлечь его из кэша.

Answer 2

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

Что касается абстракции, используйте веб-роль Azure или рабочую роль для проверки подлинности и авторизации ваших клиентов.Пусть это напишет в Blob store (s).Вы можете реализовать абстракцию, используя HTTPHandlers или WCF для непосредственной обработки запросов ввода-вывода.

Эта абстракция позволит вам преодолеть ограничение BLOB-объектов в 5000 файлов, которые вы упоминаете в комментариях выше, и позволит вам масштабировать и предоставлятьдополнительные функции для ваших клиентов.

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