К файлу хранилища BLOB-объектов Azure обращаются несколько узлов Azure

У меня есть несколько файлов формата JSON, которые отправляются в учетную запись хранения Azure в определенном контейнере. В контейнере n файлов.

И от 4 до 8 узлов, которые будут обращаться к контейнеру хранилища Azure для локальной загрузки файлов, код загрузки написан на java.

Поскольку к контейнеру одновременно обращаются n файлов и несколько файлов, как избежать ситуации, когда один и тот же файл загружается другим сервером?

Example:
 Azure container has 1.json, 2.json, 3.json, etc which are > 35 MB size.
 batch-process-node1 -> starts downloading 1.json
 batch-process-node2 -> starts downloading 2.json
 batch-process-node3 -> should not start downloading the 1.json 

Есть ли какая-то логика для каждого узла, на котором есть процесс java для однозначной загрузки файла? Можно ли настроить какой-либо параметр в контейнере хранилища Azure?

--

Попытка использовать компонент Camel Azure-bolb, используя блочный BLOB-объект (blobType).

Если вы новичок в хранилище BLOB-объектов Azure, мы приветствуем любую помощь.


person Tim    schedule 11.06.2018    source источник
comment
Вы хотите избежать одновременной загрузки файла несколькими узлами или хотите, чтобы файл загружался только одним узлом?   -  person Joey Cai    schedule 11.06.2018
comment
Если какой-либо файл выбран для загрузки одним серверным узлом, этот же файл не должен быть доступен для загрузки другим серверным узлам. Если это поможет.   -  person Tim    schedule 11.06.2018
comment
В настоящее время изучается возможность использования компонента camel azure-blob для загрузки большого двоичного объекта в распределенной среде.   -  person Tim    schedule 20.06.2018


Ответы (1)


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

azure-blob://<account>/<container>?credentials=#storagecredentials&amp;blobType=blockBlob&amp;operation=listBlobs

Примечание. Storagecredential - это bean-компонент типа StorageCredentialsAccountAndKey class.

Создал java-класс, реализующий Processor of camel, и метод process (), используя exchange.getIn (). GetBody () =>, который предоставляет итерируемый объект с ListBlobItem.

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

azure-blob://<account>/<container>/*<blobName>*?credentials=#storagecredentials&blobType=blockBlob&operation=updateBlockBlob&blobMetadata=#blobMetaData1

Примечание. BlobMetaData1 - это bean-компонент, созданный в файле контекста.

 <util:map id="blobMetaData1" map-class="java.util.HashMap">
        <entry key="someKey" value="someValue"/>
 </util:map>

Ключевой момент: в этом методе процесса класса

  1. проверьте, установлены ли метаданные или нет, если установлено, то процесс уже выбрал большой двоичный объект. поэтому он не будет выбран снова, если процесс выполняется на другом сервере.
  2. получил имя большого двоичного объекта из отдельного элемента большого двоичного объекта ListBlobItem. используя getURI () и формируя конечную точку в этом классе процессора. для вызова настраиваемой конечной точки, используемой для установки значения заголовка клиента сообщения In.

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

Затем использовал другой процессор для формирования конечной точки загрузки большого двоичного объекта.

  azure-blob://<account>/<container>/*<blobName>*?credentials=#storagecredentials&blobType=blockBlob&operation=getBlob  

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

наконец, формируется еще одна конечная точка удаления, которая будет удалена после загрузки.

person Tim    schedule 22.06.2018