AWS Конечная согласованность S3 и согласованность чтения после записи

Question

Помогите мне лучше понять эти концепции, которые я не могу понять asp полностью.

Говоря о aws S3-моделях, я попытаюсь объяснить, что я понял.

Демистифицируйте или подтвердите мне эти утверждения, пожалуйста.

прежде всего

• разговор о «чтении после записи» относится только к «новым записям» / созданию объектов, которые не были ' они существовали раньше.
• разговор о «возможной согласованности» связан с «изменением существующих объектов» (обновлением или удалением)

правильны ли эти первые концепции? тогда

• возможная согласованность: «клиент», который обращается к данным до того, как они были полностью записаны на узле, может прочитать старую версию объекта, потому что запись может быть все еще в процессе или объект, возможно, не был захвачен. Это поведение, универсально допустимое в распределенных системах, где такая согласованность типов предпочтительнее, чем другой вариант ожидания снятия какой-либо блокировки, когда объект был зафиксирован.

• чтение после записи согласованность: объекты немедленно становятся доступными для клиента, и клиент будет читать «настоящую» версию объекта, а не старую версию, и, если я хорошо понял, это верно только для нового объекта.

Если да, то почему эти методы репликации такие разные? и обеспечить эту разницу rnet согласованности?

Концепция «конечной согласованности» более естественна для gr asp, потому что вы должны учитывать «задержку» для распространения данных на разные узлы и клиент может получить доступ в это время и еще не получить fre sh данных.

Но почему «чтение после записи» должно выполняться немедленно? для распространения модификации существующей базы данных или создания новой базы данных должна иметь такую ​​же задержку. Я не могу понять разницу.

Не могли бы вы сказать мне, верны ли мои утверждения, и по-другому объяснить эту концепцию.

Answer 1

разговор о «чтении после записи» относится только к «новым записям» / созданию объектов, которых раньше не было.

Да

разговор о «возможной согласованности» связан с «изменением существующих объектов» (обновлением или удалением)

Почти правильно, но помните об одной оговорке. Вот цитата из документации :

Предостережение в том, что если вы сделаете запрос HEAD или GET к ключевому имени до создания объекта, то вскоре создадите объект. после этого последующий GET может не вернуть объект из-за возможной согласованности.

Что касается того, почему они предлагают разные модели согласованности, вот мое понимание / предположение. (Примечание: следующий контент может быть неправильным, поскольку я никогда не работал с S3 и не знаю его фактическую внутреннюю реализацию.)

S3 - распределенная система, поэтому весьма вероятно, что S3 использует некоторые служба внутреннего кеширования. Подумайте, как работает CDN, я думаю, вы можете использовать здесь аналогичную аналогию. В случае, когда вы ПОЛУЧАЕТЕ объект, ключ которого еще не находится в кеше, это промах кеша! S3 получит последнюю версию запрошенного объекта, сохранит ее в кеше и вернет вам. Это модель чтения-после-записи.

С другой стороны, если вы обновляете объект, который уже находится в кеше, то помимо репликации вашего нового объекта в другие зоны доступности, S3 необходимо проделать больше работы, чтобы обновить существующие данные в кеше. Следовательно, процесс распространения, скорее всего, будет более длительным. Вместо того, чтобы позволить вам ждать выполнения запроса, S3 принял решение вернуть существующие данные в кеше. Эти данные могут быть старой версией этого объекта. На этом завершается конечная согласованность.

Как сказал Фил Карлтон, в компьютерных науках есть только две сложные вещи: недействительность кеша и именование вещей. AWS не имеет хороших способов полностью решить эту проблему, и ему также приходится идти на некоторые компромиссы.