このページでは R2 の一貫性モデルを説明します。R2 がグローバルに強整合である範囲と、対象となる操作をまとめます。
R2 は、ほかの分散オブジェクトストレージと比べても「強整合」と言えます。この強整合性により、R2 に対する操作は常に最新（正確）な状態を見ます。クライアントは、書き込み、更新、削除の結果を、世界中ですぐに観測できます。
R2 では、強整合 と 結果整合 を次の意味で使います。
- 強整合 - 操作の結果は、すべてのクライアントが世界中ですぐに観測します。クライアントが「古い」（不整合な）状態を見ることはありません。
- 結果整合 - クライアントが操作の結果をすぐには見ないことがあります。状態が世界中へ伝播するまで、数秒から 1 分程度かかることがあります。
R2 バケットとオブジェクトに対する操作は、次の一貫性を保証します。
| 操作 | 一貫性 |
|---|---|
| 書き込み後読み取り: オブジェクトを書き込み（アップロード）してから読む | 強整合: 読み取り側は世界中ですぐに最新のオブジェクトを見ます |
| メタデータ: オブジェクトのメタデータを更新する | 強整合: 読み取り側は世界中ですぐに更新後のメタデータを見ます |
| 削除: オブジェクトを削除する | 強整合: そのオブジェクトへの読み取りは、すぐ「存在しない」エラーを返します |
| オブジェクト一覧: バケット内のオブジェクトを一覧する | 強整合: 一覧操作は、その時点のすべてのオブジェクトを返します |
| IAM: R2 Storage の権限を追加・削除する | 結果整合: 新規または更新した API キー の権限が世界中へ反映されるまで、最大 1 分かかることがあります |
補足:
- 2 つのクライアントが同じキーへ書き込む（
PUTまたはDELETE）場合、最後に完了した書き込みが採用されます。 - マルチパートアップロードでは、すべてのパートのアップロードが成功した時点から、書き込み後読み取りの一貫性が適用されます。同じパートを複数の書き込み側が（誤って）アップロードした場合は、最後の書き込みが採用されます。
- 同じバケット内でのオブジェクトコピーも、新規オブジェクトの書き込みと同じ書き込み後読み取り一貫性に従います。コピー完了後、コピー先オブジェクトはすべてのクライアントがすぐに読めます。
- R2 バケットを削除するには、先にバケットを空にする必要があります。オブジェクトが残っているバケットを削除しようとすると、
The bucket you tried to delete (X) is not empty (account Y)やBucket X cannot be deleted because it isn’t empty.などのエラーになります。バケットを空にして削除する手順は バケットを削除する を参照してください。
カスタムドメイン を R2 バケットに接続し、そのバケットから配信するオブジェクトのキャッシュを有効にすると、キャッシュ有効なドメイン経由のアクセスでは、一貫性モデルは必然的に緩くなります。
具体的には、次を想定してください。
- R2 から削除したオブジェクトでも、キャッシュに残っているあいだは取得できます。削除をすぐ反映する必要がある場合は、削除後に キャッシュをパージ します。
- デフォルトでは、Cloudflare のキャッシュは HTTP 404（Not Found）レスポンスを自動でキャッシュ します。同じパスにオブジェクトをアップロードしても、キャッシュ TTL（Time to Live）が切れて R2 から新しいオブジェクトを取得するか、キャッシュをパージ するまで、キャッシュは HTTP 404 を返し続けることがあります。
- あるキーのオブジェクトを新しいオブジェクトで上書きした場合、キャッシュ TTL の期限切れ（またはエビクション）か、キャッシュのパージまで、クライアントには以前のオブジェクトが配信され続けます。
キャッシュは Worker API バインディング や S3 API 経由のアクセスには影響しません。これらの操作はバケットへ直接行われ、キャッシュを経由しません。