Google 云存储 一个文件同时访问多个
Google Cloud Storage One file multiple access at the same time
我在我的 GAE-Projekt 中使用 GoogleCloudStorage，我想知道当我同时访问一个文件的两个实例时会发生什么。我创建了一个 PHP-script，它打开一个文件，读取它的内容，添加一些内容并像这样保存它：
$userContent = json_decode(file_get_contents("*** link ***"));
$userContent->abc = "test"; // Do some changes
file_put_contents("*** link ***", json_encode($userContent);
我担心的是，当我打开文件时，另一个实例也打开了它，数据丢失了。那么在这种情况下会发生什么呢？
- 文件是否锁定，另一个实例正在等待？
- 文件是否被锁定并且另一个实例中止？
- 数据丢失了吗？
没有锁定 - 如果您同时以不同方式修改数据，那么您的数据很可能会丢失。
Google Cloud Storage 本身不强加锁定。对 GCS 对象的读取和写入都是 atomic -- 每次读取都将完全从一个版本获取对象的内容；每次写入都将完全替换该对象。不可能存在 "intermediate stage"（对象的一部分来自一个版本，其余部分来自另一个版本）。
但是当然 很有可能 "lose data" 如果多个任务试图独立地 "modify" 一个 GCS 对象并且 w/o 不知何故他们之间同步或协商！那是因为 GCS 没有 "modifying" 对象的概念：只有 读取 对象，以及完全 替换 对象。
因此，尝试 "modify" GCS 对象的任务实际上会读取它，修改它在内存 中 的任何内容，然后用该内存的内容覆盖该对象。如果多个任务独立 "overwriting" 同一个对象，最后的覆盖将 "win"，并抹去之前的。
我不知道 "GAP-Projekt" 是什么，但假设我们实际上在谈论 GAE（根据标签），一个 GAE 应用程序的多个实例很容易在它们之间同步，使用共享资源，例如内存缓存或 GAE 数据存储。按照惯例，此类资源将用于表示哪个实例 "currently owns" 是 GCS 对象；另一个实例会等待轮到它...
也可以依赖GCS preconditions
这允许仅在读取后未更改文件的情况下更新文件。请参阅文档：
Preconditions are often used in mutating requests — uploads, deletes, copies, or metadata updates — to prevent race conditions. Race conditions can arise when the same request is sent repeatedly or when independent processes interfere with each other. For example, multiple request retries after a network interruption, or users performing a read-modify-write operation on the same object can create race conditions.
我在我的 GAE-Projekt 中使用 GoogleCloudStorage，我想知道当我同时访问一个文件的两个实例时会发生什么。我创建了一个 PHP-script，它打开一个文件，读取它的内容，添加一些内容并像这样保存它：
$userContent = json_decode(file_get_contents("*** link ***"));
$userContent->abc = "test"; // Do some changes
file_put_contents("*** link ***", json_encode($userContent);
我担心的是，当我打开文件时，另一个实例也打开了它，数据丢失了。那么在这种情况下会发生什么呢？
- 文件是否锁定，另一个实例正在等待？
- 文件是否被锁定并且另一个实例中止？
- 数据丢失了吗？
没有锁定 - 如果您同时以不同方式修改数据，那么您的数据很可能会丢失。
Google Cloud Storage 本身不强加锁定。对 GCS 对象的读取和写入都是 atomic -- 每次读取都将完全从一个版本获取对象的内容；每次写入都将完全替换该对象。不可能存在 "intermediate stage"（对象的一部分来自一个版本，其余部分来自另一个版本）。
但是当然 很有可能 "lose data" 如果多个任务试图独立地 "modify" 一个 GCS 对象并且 w/o 不知何故他们之间同步或协商！那是因为 GCS 没有 "modifying" 对象的概念：只有 读取 对象，以及完全 替换 对象。
因此，尝试 "modify" GCS 对象的任务实际上会读取它，修改它在内存 中 的任何内容，然后用该内存的内容覆盖该对象。如果多个任务独立 "overwriting" 同一个对象，最后的覆盖将 "win"，并抹去之前的。
我不知道 "GAP-Projekt" 是什么，但假设我们实际上在谈论 GAE（根据标签），一个 GAE 应用程序的多个实例很容易在它们之间同步，使用共享资源，例如内存缓存或 GAE 数据存储。按照惯例，此类资源将用于表示哪个实例 "currently owns" 是 GCS 对象；另一个实例会等待轮到它...
也可以依赖GCS preconditions
这允许仅在读取后未更改文件的情况下更新文件。请参阅文档：
Preconditions are often used in mutating requests — uploads, deletes, copies, or metadata updates — to prevent race conditions. Race conditions can arise when the same request is sent repeatedly or when independent processes interfere with each other. For example, multiple request retries after a network interruption, or users performing a read-modify-write operation on the same object can create race conditions.