我正在尝试在Google云中的多个实例之间同步操作。
在创建新实例的映像的主文件夹中，有几个文件的命名如下：1.txt，2.txt，3.txt，... {{ 1}}。
我在Google云存储存储桶中有另一个文件，名为50000.txt，该文件在一行中包含一个数字，该数字指示所有正在运行的Google云实例正在处理的最新文件。最初，该文件如下所示：
gs://bucket/current_file.txt现在，我正在一个一个地创建多个Google实例。实例具有如下启动脚本：
0
因此，此脚本将下载另一个实例正在处理的当前文件的值，然后将其递增1，然后开始处理递增的文件。 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会正确更新，但是当我在运行多个实例时，有时gs://bucket/current_file.txt中的值会升至一个值，然后又不稳定地回落到一个降低的值
我的假设是，两个不同的实例试图同时上传同一文件，并弄乱了文本文件中的整数值。
是否始终可以锁定文件，以便其他实例在一个实例覆盖gs://bucket/current_file.txt之前等待？
如果没有，有人可以建议其他任何机制，一旦一个实例正在处理current_file编号，我就可以通过该机制更新它，然后可以将其传达给其他实例，以便他们可以在完成处理后开始处理以下文件一个手头的文件？
答案 0 :(得分：2)
您是正确的。在您的体系结构中，您需要某种机制来锁定df.dropna(axis=1, thresh=2, subset=col_list,inplace = True)计数器，以便一次只能更改一个进程的值。您希望能够在一个进程打开该文件以对其进行递增时对其应用互斥或锁定，以使另一进程无法同时对其进行递增。
我建议您考虑使用其他方法。
即使您能够锁定计数器，您的“工人”也将阻塞，等待他们轮流增加此变量，以使他们能够继续处理文件。您还同时限制了一次处理一个文件，这可能会使您的进程一次抓取一批文件更为有效。
您可以考虑多种方法。
如果您的文件集是预先确定的，即您始终有50k。开始时，您可以决定要使用多少个工人，然后让他们每个人解决问题。如果您选择了1000个工作程序，则可能会为第一个工作程序分配1.txt..50.txt，为第二个工作程序分配51.txt..99.txt等。如果文件中有空格，工作程序将跳过丢失的文件。
在更复杂的情况下，当在存储桶中随机且连续地创建文件时，通常的做法是将处理排队。看一下Task Queues和Cloud Pub/Sub。通过这种方法，您可以在文件到达时对其进行跟踪。对于每个文件，您都会加入一个作业来处理它。同时使用“任务队列”和“发布/订阅”，您可以创建推式或拉式队列。在这两种方法中，您都将编写一个工作程序，该工作程序从队列中接收作业（文件），对其进行处理，并对已处理的文件执行某些操作。与较简单的情况相比，该方法有2个优点：第一个优点是您可以根据队列深度（要处理的文件数）动态减少工作程序数。第二个问题是，如果一个工作程序失败，它将不会从队列中取出作业，因此另一个工作程序可以替换它并完成文件处理。
您可以将已处理的文件移动到“已处理”存储桶中以跟踪完成情况。这样，如果作业失败，则只需要重新处理尚未处理的文件即可。
最后，与其一一对应地创建实例，不如使用Managed Instance Groups进行自动缩放，或者考虑使用Kubernetes。这两种技术都可以帮助您从单个模板中克隆许多相似的过程。尽管这两种解决方案都不能解决您的协调问题，但是两种解决方案都可以帮助您管理所有工作人员。
希望有帮助！