S3 последняя измененная временная метка для согласованных в конечном итоге PUT перезаписи
Документы AWS S3 утверждают, что:
Amazon S3 предлагает возможную согласованность для записи PUTS и DELETES во всех регионах.
http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html
Время до достижения полной согласованности может варьироваться. В течение этого периода запросы GET могут возвращать предыдущий объект или обновленный объект.
Мой вопрос:
Когда обновляется последняя измененная временная метка? Обновляется ли он сразу после успешного завершения перезаписи PUT, но до достижения полной согласованности, или он обновляется только после достижения полной согласованности?
Я подозреваю, что первое, но я не могу найти документацию, которая ясно заявляет об этом.
1 ответ
Last-Modified отметка времени должна соответствовать Date значение, возвращаемое в заголовках ответа от успешного PUT запрос.
Насколько мне известно, это явно не задокументировано, но может быть получено из того, что задокументировано.
Когда вы перезаписываете объект, это не сама перезапись, которая может быть отложена из-за возможной модели согласованности - это доступность перезаписанного содержимого на данном узле S3 (S3 реплицируется на несколько узлов в пределах области S3).
Last-Modified временная метка, как и остальные метаданные, устанавливается во время создания объекта и впоследствии остается неизменной.
На самом деле это не время "модификации" объекта, это время создания объекта. Объяснение может показаться педантичным, но оно является точным в самом строгом смысле: объекты S3 и их метаданные на самом деле вообще не могут быть изменены, их можно только перезаписать. Когда вы "перезаписываете" объект в S3, на самом деле вы создаете новый объект, повторно используя ключ старого объекта (путь + имя файла). Доступность этого нового объекта на данном узле S3 (репликация) - это то, что может быть задержано возможной моделью согласованности... а не фактическим созданием нового объекта, который перезаписывает старый... поэтому не было бы никаких причин для Last-Modified быть подверженным влиянию задержки репликации (при условии, что существует задержка репликации - возможная согласованность иногда может быть неотличима от немедленной согласованности).
Это то, что делает S3 абсолютно ужасным.
В основном в Linux у вас есть mtime - время последнего изменения файла в файловой системе. Любой клиент S3 может собрать время mtime и установить время последнего изменения на S3, чтобы оно сохраняло время последнего изменения.
Вместо этого Amazon просто делает это на основе создания объекта, и это, по сути, серьезная проблема, если вы когда-нибудь просто захотите использовать данные как данные за пределами исходного приложения, которое их туда поместило.
Поэтому, если вы загружаете файл с S3, ваш клиент, скорее всего, установит измененное время, и если он был загружен в s3 сразу после создания, то у вас будет по крайней мере почти правильная метка времени. Но в реальности вы можете сделать снимок, и он может не попасть с вашего телефона через приложение, через стек и на S3 в течение нескольких дней!
Это даже без учета повторной закачки файла на s3. Что усугубит проблему, так как вы можете повторно загрузить его годы спустя. S3 будет действовать так же, как Last-Modified годы спустя, когда файл фактически не был изменен.
Они действительно должны позволить вам установить это, но они остаются неоднозначными и чрезмерно задокументированными в других областях, чтобы это было трудно понять.