生命周期概述
随着时间的推移,存储在 OSS 中的数据访问热度通常会逐渐降低。若持续使用高成本的标准存储保存冷数据,或依赖人工清理大量日志、备份文件,既不经济,效率也低。生命周期管理功能允许您创建自动化规则,在文件满足特定条件(如创建超过30天)后,自动将其转换为成本更低的存储类型(如低频、归档),或直接删除,实现智能化、低成本的数据全生命周期管理。
工作原理
生命周期管理通过用户定义的规则,对存储空间(Bucket)内的文件(Object)进行自动化操作。生命周期规则创建后的24小时内,OSS会加载规则。规则加载完成后,OSS 会在固定的时间周期(通常是次日 UTC 时间 0点,即北京时间 8 点后)扫描并执行符合条件的规则。
一条生命周期规则主要由三部分构成:
控制对象: 定义规则对哪些文件生效,可基于文件前缀(Prefix)、对象标签(Tag)、或文件大小(ObjectSize)来筛选目标文件。
生命周期规则目前不支持通配符匹配、后缀匹配以及正则匹配。
执行动作: 定义对筛选出的文件做什么操作。主要包括:
存储类型转换(Transition): 将文件转储到低频访问、归档、冷归档等更低成本的存储类型。
过期删除(Expiration): 文件达到指定生命周期后将其删除。
清理碎片(AbortMultipartUpload): 自动删除超过指定时间仍未合并的分片上传任务。
触发策略:定义对筛选出的文件基于什么条件触发:
最后一次修改时间(Last-Modified-Time): 根据文件的最后修改时间为基准进行存储类型转换和删除,适用于日志、备份等生命周期明确的数据,可自动进行存储类型转换或删除以节省成本。
最后一次访问时间(Last-Access-Time):启用访问跟踪功能后,根据文件的最近访问时间智能切换存储类型,适合访问模式不确定的场景,如素材库。可在数据冷却时降级,访问时自动恢复。
可参考生命周期配置元素配置生命周期策略。
配置生命周期
自动清理过期的日志文件
服务器每天会生成大量日志并上传至指定目录。您可配置基于最后修改时间的生命周期规则,在达到指定天数后删除Bucket内的所有Object,释放存储空间、降低存储成本。
数据的冷热分层存储
对于访问频率不确定的数据(如网站图片、在线视频、文档等),建议启用访问跟踪功能,并使用最后一次访问时间的生命周期规则实现数据智能分层。系统将根据实际访问情况,自动将冷数据转入低频、归档或冷归档存储,实现智能分层与成本优化。
自动清理历史版本
开启版本控制后,针对数据的覆盖和删除操作将会以历史版本的形式保存下来。当Bucket累积了大量的历史版本或者过期删除标记时,可使用最后一次修改时间的生命周期规则结合版本控制降低存储成本,在文件达到指定时间后自动删除,从而减少存储成本并有效提升列举Object的性能。
自动清理上传时产生的碎片
在使用分片上传大文件过程中,若上传中断,系统会保留未合并的分片(Part),这些分片将持续计费。可配置生命周期规则自动清理超过指定时间的未完成分片,避免不必要的资源占用。
除上述场景外,如需实现更精细的数据管理策略,您可参考生命周期配置示例,根据业务需求组合不同规则,实现对 Bucket 中数据的精细化管理。
多条生命周期规则
为确保配置的多条生命周期规则按预期生效,需要理解两个核心机制:规则的执行优先级和配置的覆盖机制。
规则执行优先级
同一个Bucket可以配置多条生命周期规则,且规则之间互不影响。因此,同一个Object可能会命中多条规则,需根据所有规则的命中结果决定最终操作。
当多条规则同时匹配同一文件时,按以下优先级执行:删除 Object > 转为深度冷归档 > 转为冷归档 > 转为归档 > 转为低频访问 > 转为标准。
删除操作始终优先于存储转换。建议将删除规则的时间设置得比转储规则更长,避免文件在转储完成前被删除。
执行示例
假设指定了以下两条生命周期规则,且两条规则均命中相同的Object。
规则1:指定将最后一次修改时间超过365天的Object转为低频访问类型。
规则2:指定将最后一次修改时间超过365天的Object删除。
执行结果:规则命中的Object将在距离其最后一次修改时间超过365天后删除。
配置的覆盖机制
在使用控制台时,无需关心配置覆盖问题。每次新增、修改规则时,控制台会自动读取当前配置并合并后提交,避免误操作导致原有规则丢失。但在使用 ossutil、SDK或直接调用 API 的方式配置生命周期规则时,需格外注意:每次调用 PutBucketLifecycle 都会完全覆盖当前 Bucket 的所有生命周期配置,若只提交新规则而未包含原有规则,将导致原有规则被删除并失效。
示例说明
如果您希望在已有规则的基础上新增一条规则,需按以下步骤操作:
获取 当前已生效的所有生命周期规则(例如规则1)
添加 新规则(例如规则2)
重新提交 包含全部规则(规则1 + 规则2)的完整配置
注意:如果仅提交包含新规则(规则2)的配置,而未包含原有规则(规则1),则规则1会被删除,不再生效。
应用于生产环境
为确保在生产环境中安全、高效地使用生命周期管理,建议:
先测试,后部署: 强烈建议先在测试 Bucket 中创建规则,验证其行为完全符合预期后,再应用到生产环境的 Bucket。
谨慎使用删除规则: 对配置了过期删除的规则,务必精确设置前缀,避免规则范围扩大导致重要数据被意外删除。
开启版本控制作为保障: 对于关键业务数据,建议开启 Bucket 的版本控制功能。这样,即使当前版本文件被生命周期规则误删,仍有机会从历史版本中恢复数据。
阶梯式转换避免额外费用: 在设计存储类型转换策略时,确保后一阶段的触发时间晚于前一阶段的触发时间与该存储类型最低存储时长之和,以避免提前转换带来的费用。
错误示例: 标准存储
30天
-> 低频存储40天
-> 归档存储。此配置会导致低频文件仅存储10天(< 30天
)就被转走,从而产生费用。正确示例: 标准存储
30天
-> 低频存储90天
-> 归档存储。(30天转为低频,再经过60天满足归档最低要求,共90天)。
计费说明
配置生命周期规则本身不收费。费用产生于规则被执行时以及执行后带来的存储状态变化。
请求费用:当生命周期规则执行存储类型转换、删除Object或删除Part操作时,系统会发起
Put
类型请求调用,并按请求次数收取请求费用,计费规则可参考生命周期费用说明。对于包含海量小文件的 Bucket,此费用可能较为显著,请在配置前进行评估。
存储费用:文件转换到新存储类型后,将按新类型的单价计费。
重要低频、归档、冷归档等存储类型有最低存储时长要求(如低频为30天,归档为60天)。如果生命周期规则在文件存满最低时长之前就将其删除或再次转换,需要支付剩余天数的存储费用作为补偿。为避免产生转储或者删除产生的不足规定时长容量费用(条件),可参考如何避免产生存储不足规定时长容量费用?,确保满足其最低存储时长后再进行转储或者删除。
数据取回费用:生命周期规则本身不会产生数据取回费用。但文件被转换为低频、归档等类型后,在访问这些文件时,会产生相应的数据取回费用。