← Cloudflare R2 / r2 / reference
Model konzistence
Tato stránka popisuje model konzistence R2 včetně toho, kde je R2 silně a globálně konzistentní a na které operace se to vztahuje.
R2 lze popsat jako „silně konzistentní“, zejména ve srovnání s jinými distribuovanými systémy pro objektové úložiště. Tato silná konzistence zajišťuje, že operace vůči R2 vidí nejnovější (přesný) stav: klienti by měli okamžitě a globálně vidět účinky jakékoli operace zápisu, aktualizace nebo odstranění.
Terminologie
V kontextu R2 silná konzistence a eventuální konzistence mají následující významy:
- Silně konzistentní - Projev operace uvidí okamžitě a globálně všichni klienti. Klienti nezaznamenají 'neaktuální' (nekonzistentní) stav.
- Eventuální konzistence - Klienti nemusí projev operace zaznamenat okamžitě. Stav se může globálně šířit určitou dobu, obvykle od několika sekund do minuty.
Operace a konzistence
Operace prováděné s buckety a objekty R2 dodržují následující záruky konzistence:
| Akce | Konzistence |
|---|---|
| Read-after-write: zapište (nahrajte) objekt a poté jej přečtěte | Silně konzistentní: čtenáři okamžitě uvidí nejnovější objekt globálně |
| Metadata: Aktualizace metadat objektu | Silně konzistentní: čtenáři okamžitě uvidí aktualizovaná metadata globálně |
| Odstranění: odstranění objektu | Silně konzistentní: čtení tohoto objektu okamžitě vrátí chybu „does not exist“ |
| Výpis objektů: Seznam objektů v bucketu | Silně konzistentní: operace list vypíše všechny objekty platné k danému okamžiku |
| IAM: přidávání a odebírání oprávnění R2 Storage | Eventuální konzistence: nový nebo aktualizovaný API klíč může trvat až minutu, než se oprávnění globálně projeví |
Další poznámky:
- V případě, že dva klienti zapisují (
PUTneboDELETE) do stejného klíče poslední dokončený zápis "vyhrává". - Při vícedílném nahrávání platí konzistence read-after-write i po úspěšném nahrání všech částí. Pokud je stejná část omylem nahrána z více zdrojů zápisu, uplatní se poslední zápis.
- Kopírování objektu v rámci stejného bucketu se řídí stejnou read-after-write konzistencí jako zápis nového objektu. Jakmile se operace kopírování dokončí, je „zkopírovaný“ objekt okamžitě čitelný pro všechny klienty.
- Chcete-li odstranit bucket R2, musí být před odstraněním úplně prázdný. Pokud se pokusíte odstranit bucket, který stále obsahuje objekty, zobrazí se chyba podobná této:
The bucket you tried to delete (X) is not empty (account Y)neboBucket X cannot be deleted because it isn’t empty.Pokyny k vyprázdnění a odstranění bucketu najdete v Odstranění bucketů.
Ukládání do mezipaměti
Při připojování vlastní doména k R2 bucketu a povolení cachování objektů poskytovaných z tohoto bucketu je model konzistence nutně méně striktní při přístupu k obsahu přes doménu s povoleným cachováním.
Konkrétně můžete očekávat:
- Objekt, který smažete z R2, ale který je stále uložen v mezipaměti, zůstane dál dostupný. Měli byste vymazat cache po odstranění objektů, pokud potřebujete, aby se toto odstranění projevilo.
- Cloudflare cache bude standardně ukládat do mezipaměti odpovědi HTTP 404 (Not Found) automaticky. Pokud nahrajete objekt na stejnou cestu, cache může nadále vracet chyby HTTP 404, dokud nevyprší TTL (Time to Live) cache a nový objekt se nenačte z R2 nebo mezipaměť je vymazána.
- Když je objekt pro daný klíč přepsán novým objektem, starý (předchozí) objekt se klientům bude nadále poskytovat, dokud nevyprší TTL mezipaměti (nebo dokud objekt není vyřazen), případně dokud se mezipaměť nevyprázdní.
Cache neovlivňuje přístup přes Vazby Worker API nebo S3 API, protože tyto operace probíhají přímo proti bucketu a neprocházejí mezipamětí.