Wie verhindert man das Überschreiben von Objekten durch bedingte Schreibvorgänge

Bei bedingten Schreibvorgängen können Sie Ihrer Schreibanforderung einen zusätzlichen Header hinzufügen, um Vorbedingungen für Ihren S3-Vorgang festzulegen. Auf diese Weise können Sie das Überschreiben vorhandener Daten verhindern, indem überprüft wird, ob sich in Ihrem Bucket noch kein Objekt mit demselben Schlüsselnamen befindet. Bedingte Schreibvorgänge funktionieren für API Anfragen in Allzweck-Buckets und Verzeichnis-Buckets.

Wenn Sie ein Objekt auf Amazon S3 hochladen, geben Sie den Schlüsselnamen an. Der Schlüsselname ist eine eindeutige Kennung eines Objekts in einem Bucket, bei der Groß- und Kleinschreibung berücksichtigt wird. Wenn Sie ein Objekt mit einem identischen Schlüsselnamen in einen Bucket hochladen, für den keine Version verwendet wurde oder dessen Version gesperrt wurde, wird das Objekt überschrieben. In einem versionierten Bucket wird das zuletzt hochgeladene Objekt zur aktuellen Version des Objekts.

Bei bedingten Schreibvorgängen wird während des WRITE Vorgangs geprüft, ob ein Objekt vorhanden ist. Wenn im Bucket ein identischer Schlüsselname gefunden wird, schlägt der WRITE Vorgang fehl. Bei bedingten Schreibvorgängen können mehrere Clients in denselben Bucket schreiben, ohne dass die Möglichkeit besteht, bestehende Objekte zu überschreiben.

Um bedingte Schreibvorgänge ausführen zu können, benötigen Sie die s3:PutObject entsprechende Genehmigung. Diese Berechtigung ermöglicht es dem Aufrufer, zu überprüfen, ob Objekte im Bucket vorhanden sind. Sie können bedingte Schreibvorgänge mit vorsigniertem mit URLs dem verwenden. AWS SDKs

Unterstützt APIs

Die folgende APIs S3-Unterstützung mit bedingten Schreibvorgängen:

Sie können die folgenden Header verwenden, um ein Objekt zu schreiben, das vom Objektschlüsselnamen abhängig ist. Hinweise zu Objektschlüsselnamen finden Sie unter,Benennen Amazon S3 S3-Objekten.

PutObject

aws s3api put-object --bucket amzn-s3-demo-bucket --key dir-1/my_images.tar.bz2 --body my_images.tar.bz2 --if-none-match "*"    

Weitere Informationen zu diesen Headern finden Sie unter PutObjectin der Amazon Simple Storage Service API Reference.

CompleteMultipartUpload

aws s3api complete-multipart-upload --multipart-upload file://mpustruct --bucket amzn-s3-demo-bucket --key dir-1/my_images.tar.bz2 --upload-id uploadID --if-none-match "*"      

Weitere Informationen zu diesen Headern finden Sie unter CompleteMultipartUploadin der Amazon Simple Storage Service API Reference.

Bedingtes Schreibverhalten

Bedingte Schreibvorgänge werden anhand vorhandener Objekte in einem Bucket ausgewertet. Wenn im Bucket kein Objekt mit demselben Schlüsselnamen vorhanden ist, ist der Schreibvorgang erfolgreich, was zu einer 200 Antwort führt. Wenn ein Objekt vorhanden ist, schlägt der Schreibvorgang fehl, was zu einer 412 Precondition Failed Antwort führt. Bei Buckets mit aktivierter Versionierung prüft S3 im Rahmen der bedingten Bewertung, ob eine aktuelle Objektversion mit demselben Namen vorhanden ist. Wenn es keine aktuelle Objektversion mit demselben Namen gibt oder wenn es sich bei der aktuellen Objektversion um eine Löschmarke handelt, ist der Schreibvorgang erfolgreich. Andernfalls führt dies zu einem fehlgeschlagenen Schreibvorgang mit einer 412 Precondition Failed Antwort.

Wenn mehrere bedingte Schreibvorgänge für denselben Objektnamen ausgeführt werden, ist der erste abgeschlossene Schreibvorgang erfolgreich. Amazon S3 schlägt dann nachfolgende Schreibvorgänge mit einer 412 Precondition Failed Antwort fehl.

Sie können auch bei gleichzeitigen Anfragen eine 409 Conflict Antwort erhalten, wenn eine Löschanforderung für ein Objekt erfolgreich ist, bevor ein bedingter Schreibvorgang für dieses Objekt abgeschlossen werden kann. Das liegt daran, dass die Löschanforderung Vorrang vor dem zuvor initiierten bedingten Schreibvorgang hat. Wenn Sie bedingte Schreibvorgänge mit verwendenPutObject, werden Uploads möglicherweise erneut versucht, nachdem ein Fehler aufgetreten ist. 409 Bei Verwendung CompleteMultipartUpload muss der mehrteilige Upload erneut initiiert werden, um das Objekt nach Erhalt eines Fehlers erneut hochzuladen. CreateMultipartUpload 409

Stellen Sie sich die folgenden Szenarien vor, in denen zwei Clients Operationen auf demselben Bucket ausführen.

4.1.2 Vorbedingung: Fehlgeschlagene Antwort

Bei bedingten Schreibvorgängen werden Anfragen für mehrteilige Uploads nicht berücksichtigt, da es sich bei diesen noch nicht um vollständig geschriebene Objekte handelt. Stellen Sie sich das folgende Beispiel vor, in dem Client 1 ein Objekt mithilfe eines mehrteiligen Uploads hochlädt. Während des mehrteiligen Uploads kann Client 2 dasselbe Objekt mit dem bedingten Schreibvorgang erfolgreich schreiben. Wenn Client 1 anschließend versucht, den mehrteiligen Upload mithilfe eines bedingten Schreibvorgangs abzuschließen, schlägt der Upload fehl, da das Objekt bereits existiert.

409 Reaktion auf Konflikte

Wenn eine Löschanforderung erfolgreich ist, bevor eine bedingte Schreibanforderung abgeschlossen werden kann, gibt Amazon S3 eine 409 Conflict Antwort für den Schreibvorgang zurück. Das liegt daran, dass die zuvor initiierte Löschanforderung Vorrang vor dem bedingten Schreibvorgang hat. Betrachten Sie das folgende Beispiel, in dem eine Datei in einem Bucket puppy.txt vorhanden ist. Client 1 startet einen mehrteiligen Upload für eine andere Datei, die ebenfalls benannt ist, puppy.txt mit der Absicht, den mehrteiligen Upload mit einem bedingten Schreibvorgang abzuschließen. Während des Uploads löscht Client 2 puppy.txt aus dem Bucket. Wenn Client 1 versucht, seine eigene puppy.txt Datei mit einem bedingten Schreibvorgang hochzuladen, schlägt dies fehl und es wird eine 409 Conflict Antwort angezeigt. CompleteMultipartUpload In solchen Fällen müssen Sie einen neuen mehrteiligen Upload initiieren.