Как синхронизировать число между несколькими экземплярами облака Google с помощью облачного хранилища Google?

Question

Я пытаюсь синхронизировать операцию между несколькими экземплярами в облаке Google.

В домашней папке изображения, из которой я создаю новые экземпляры, у меня есть несколько файлов с такими именами: 1.txt, 2.txt, 3.txt, ... 50000.txt.

У меня есть другой файл в облачном хранилище Google с именем gs://bucket/current_file.txt, который содержит число в одной строке, указывающее последний файл, которыйобрабатывается всеми запущенными экземплярами облака Google.Первоначально этот файл выглядит следующим образом:

0

Теперь я создаю несколько экземпляров Google по одному.У экземпляров есть сценарий запуска, подобный следующему:

gsutil cp gs://bucket/current_file.txt /home/ubuntu/;
past_file=`tail /home/ubuntu/current_file.txt`;
current_file=$((past_file+1));
echo $current_file > /home/ubuntu/current_file.txt;
gsutil cp /home/ubuntu/current_file.txt gs://bucket/;
process.py /home.ubuntu/$current_file.txt;

Таким образом, этот сценарий загружает значение текущего файла, который обрабатывается другим экземпляром, затем увеличивает его на 1 и начинает обрабатывать увеличенный файл.Также gs://bucket/current_file.txt обновляется, чтобы другие экземпляры знали имя следующего файла, который они могут начать обрабатывать.Когда у меня работает только 1 экземпляр, gs://bucket/current_file.txt обновляется должным образом, но когда я запускаю несколько экземпляров, иногда значение в gs://bucket/current_file.txt увеличивается до значения, а затем ошибочно возвращается к уменьшенному значению.

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

В любом случае возможно ли заблокировать файл, чтобы другие экземплярыподождите, пока один экземпляр не сможет перезаписать gs://bucket/currrent_file.txt?

Если нет, может кто-нибудь предложить какой-либо другой механизм, с помощью которого я могу обновить номер current_file, когда он обрабатывается одним экземпляром, а затем может быть передан другомуэкземпляры, чтобы они могли начать обработку следующих файлов, когда они завершат обработку файла под рукой?

Answer 1

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

Я рекомендую рассмотреть альтернативные подходы.

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

Существуют различные подходы, которые вы должны рассмотреть.

Если ваш набор файлов предопределен, то есть у вас всегда есть 50k.Когда вы начинаете, вы можете решить, сколько работников вы хотите использовать, а затем дать каждому из них часть решаемой проблемы.Если вы выбрали 1000 рабочих, первому можно присвоить 1.txt..50.txt, второму 51.txt..99.txt и т. Д. Если в файлах есть пробелы, рабочий пропустит отсутствующий файл.

В более сложном сценарии, когда файлы создаются в корзине случайным образом и постоянно, обычной практикой является постановка в очередь обработки.Взгляните на Очереди задач и Cloud Pub / Sub .При таком подходе вы отслеживаете файлы по мере их поступления.Для каждого файла вы ставите в очередь задание на его обработку.Обе задачи очереди и Pub / Sub вы можете создавать push или pull очереди.При любом подходе вы пишете работника, который принимает задания (файлы) из очереди, обрабатывает их и что-то делает с обработанным файлом.Этот подход имеет 2 преимущества по сравнению с более простым случаем: во-первых, вы можете динамически увеличивать | уменьшать количество рабочих на основе глубины очереди (количество файлов, которые нужно обработать).Во-вторых, в случае сбоя работника он не возьмет задание из очереди, поэтому другой работник может заменить его и завершить обработку файла.

Вы можете переместить обработанные файлы в «обработанное» ведро.отслеживать завершение.Таким образом, если ваша работа не удалась, вам нужно перезапустить только с файлами, которые еще не были обработаны.

Наконец, вместо того, чтобы создавать экземпляры один за другим, посмотрите на автоматическое масштабирование с помощью ManagedГруппы экземпляров или, возможно, рассмотрите возможность использования Kubernetes.Обе эти технологии помогают вам клонировать много похожих процессов из одного шаблона.Хотя ни одно из этих решений не решит вашу проблему с координацией, любое из них поможет вам управлять всеми работниками.

Надеюсь, это поможет!