← Cloudflare R2 / r2 / reference
Модель согласованности
Эта страница описывает модель согласованности R2, включая случаи строгой глобальной согласованности и операции, к которым это применяется.
R2 можно назвать «строго согласованным» хранилищем, особенно в сравнении с другими распределёнными системами объектного хранения. Эта строгая согласованность гарантирует, что операции в R2 отражают самое актуальное (точное) состояние: клиенты должны видеть результат любой операции записи, обновления и/или удаления сразу и повсеместно.
Терминология
В контексте R2 строгая согласованность и итоговая согласованность имеют следующие значения:
- Строгая согласованность : результат операции будет виден всем клиентам сразу и повсеместно. Клиенты не увидят «устаревшее» (несогласованное) состояние.
- Согласованность в конечном счёте : клиенты могут не сразу увидеть результат операции. Состоянию может потребоваться некоторое время (обычно от нескольких секунд до минуты), чтобы распространиться по всей сети.
Операции и согласованность
Операции с бакетами и объектами R2 соответствуют следующим гарантиям согласованности:
| Действие | Согласованность |
|---|---|
| Чтение после записи: сначала запишите (загрузите) объект, затем прочитайте его | Строгая согласованность: пользователи сразу увидят актуальный объект по всему миру |
| Метаданные: обновление метаданных объекта | Строгая согласованность: пользователи сразу увидят обновлённые метаданные по всему миру |
| Удаление: удаление объекта | Строгая согласованность: чтение этого объекта сразу вернёт ошибку «does not exist» |
| Список объектов: получение списка объектов в бакете | Строгая согласованность: операция List вернёт все объекты, существовавшие на тот момент |
| IAM: добавление и удаление разрешений R2 Storage | Согласованность в конечном счёте: новый или обновлённый ключ API может занять до минуты, прежде чем разрешения вступят в силу глобально |
Дополнительные примечания:
- Если два клиента одновременно выполняют запись (
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) автоматически. Если вы загрузите объект по тому же пути, кеш может продолжать возвращать HTTP 404 до истечения TTL кеша (время жизни, Time to Live), после чего новый объект будет получен из R2 или кеш очищается.
- Когда объект для заданного ключа перезаписывается новым, старый (предыдущий) объект продолжает отдаваться клиентам до истечения TTL кеша (или вытеснения объекта), либо до очистки кеша.
Кеш не влияет на доступ через Привязки Worker API или S3 API, поскольку эти операции выполняются напрямую с бакетом и не проходят через кеш.