概述

存放在 BOS 中的文件通常会发生归档下沉、删除等涉及到文件生命周期的操作。一般情况下，文件在新建后的短期内会被频繁读取访问，随着时间的推移，该文件的读取次数将变少，进而变成"冷文件"，即不再被频繁的访问。到最后，该文件将会被最终删除。用户如果手工维护数据的生命周期，则费时费力；但如果不去维护，则数据始终存放在标准存储里会产生不菲的费用。因此，BOS 提供生命周期管理功能，以帮助用户自动化地完成数据的生命周期管理，实现数据从创建到归档到删除的自动管理流程，从而节约人力和存储费用。

文件生命周期管理方式

为了使数据管理更加便捷与智能，我们在保持【基础生命周期管理】（原生命周期管理）的基础上，又支持了【智能分层】，智能分层不仅可根据文件访问频次进行自动沉降，也可根据文件的访问情况进行智能冷热转化，自动升级至标准或低频存储，该功能提供了数据存储的成本与读写性能最优解决方案。

智能分层与基础生命周期管理区别

方式	规则配置	适合场景	转化模式	转化存储类型
智能分层	一键开启	访问模式不固定或者无法预估访问模式的数据	支持数据降冷，也可按需回暖	不支持归档与多az存储类型，其余均支持
基础生命周期管理	配置具体的规则	可预估访问模式	单向降冷	全部支持

功能说明

存储桶仅支持配置【基础生命周期管理】或【智能分层】，二者不可同时设置。

智能分层

• 存储桶开启智能分层，系统将周期性地监测数据访问次数，在持续一段时间没有数据访问时，将数据转移至存储成本更低的访问层。如果数据重新被访问，则会被重新转移到高频访问层上，保障数据读取性能。
• 支持文件从标准存储-〉低频存储-〉冷存储 或冷存储-〉低频存储-〉标准存储；
• 可配置删除文件与碎片（分片上传任务中，未完成的文件碎片）定期清除，支持按照指定固定天数后执行删除操作， 规则中计算起始时间以 Object 的创建时间为准，删除优先级高于转化，到期会执行删除；
• 配置规则后您可通过控制台存储桶数据分析查看单个存储桶沉降与回暖数据量。

智能分层注意事项

• 不支持转化为归档存储，标准存储-多AZ，低频存储-多AZ；
• 存储桶仅可配置一条规则。

基础生命周期

基础生命周期管理支持如下功能

• 自定义时间换存储类型，从标准存储转低频存储、转冷存储、转归档存储；或从标准存储-多 AZ 到低频存储-多 AZ；
• 定时删除不再需要的数据；
• 清除过期的三步上传数据。

从场景上划分，基础生命周期管理支持两种模式

• 数据达到一定寿命后自动归档：如定义所有创建时间超过30天的数据自动转为存储费用更为低廉的低频存储；
• 数据达到一定寿命后自动删除：如定义所有创建时间超过30天的数据自动删除。

基础生命周期注意事项

• 每个 Bucket 可以有至多 1000 条规则;
• BOS 生命周期规则设置后会在一天内生效;
• 规则生效后，BOS 会对符合条件的 Object 进行相应的处理，但处理需要一定的时间，不一定能马上看到效果。一般情况下，沉降或删除的时间为几小时，但若沉降数据量较大，则可能会在几天甚至更长的时间完成下沉或者删除；
• 规则中计算的时间（即 Object 的“年龄”）以 Object 的创建时间为准，而不是生命周期规则的创建／修改时间;
• BOS 只保存文件的最后修改时间，即 last-modified 时间；如果您不更新 meta 或者覆盖文件，那么 last-modified 就是创建时间。所以生命周期中的“创建时间”其实是 last-modified 时间。
• 基于文件访问时间记录的生效策略，目前仅北京和苏州区域支持。
• 低频存储、冷存储和归档存储的最低存储时间分别为 30 天，60 天和 180 天。您配置的生命周期沉降/删除规则需要满足最低存储时间的要求。若您配置的时间小于最低存储时间时间，控制台将会产生提示，请您根据提示中的要求进行配置。
• 单 AZ 类型文件仅能沉降到单 AZ 类型文件，无法沉降到多 AZ 类型文件；标准存储-多AZ 类型文件只能沉降到低频存储-多 AZ 类型文件。
• 发生生命周期沉降时，原类型若需要取回，则会产生取回费用。同时，沉降完成后，原类型文件会被删除，也会产生请求费用。比如，一个低频存储类型文件沉降到冷存储，那么 BOS 需要先获取原低频存储文件，该操作产生取回费用；当文件成功沉降为冷存储文件后，原低频存储文件会被删除，该操作产生 Delete 请求费用，该请求费用包含在写请求费用中。

配置方式

• 通过 Console 控制台管理生命周期请参考管理生命周期。

• 通过 API 管理生命周期：

  • PutBucketlifecycle
  • GetBucketLifeCycle
  • DeleteBucketLifeCycle

下面重点介绍一下通过 API 管理生命周期时的规则文件语法。

规则定义

BOS提供的生命周期管理服务通过定义规则，并为每条规则设定动作来实现。

注意：

• BOS基础生命周期是天级别执行；
• BOS基础生命周期规则设置后会在一天内执行，但是执行时规则不一定满足，最坏情况下，需要两天。
• 规则生效后，BOS会对符合条件的Object进行相应的处理，但处理需要一定的时间(一般情况下为几小时)，所以设置规则后不一定能马上看到效果。
• 规则中计算的时间（即Object的“年龄”）以Object的创建时间为准，而不是生命周期规则的创建／修改时间。
• BOS只保存文件的最后修改时间，即last-modified时间；如果用户不更新meta或者覆盖文件，那么last-modified就是创建时间。所以生命周期中的“创建时间”其实是last-modified时间。

规则定义遵循以下原则：

• 规则基于bucket定义；
• 基础生命周期管理每个bucket可以有至多1000条规则，智能分层仅支持配置一条，且二者不可同时配置；

以下是一个基础生命周期规则示例，该规则附属于名为samplebucket的bucket，包含3条规则项：

• 2016年9月7日后删除prefix1下的所有文件；
• 自动将prefix2下创建超过30天的文件转入低频存储；

• 自动清除prefix3下超过5天未完成的三步上传。

   {
  "rule": [
      {
          "id": "sample-rule-delete-prefix", 
          "status": "enabled", 
          "resource": [
              "samplebucket/prefix1/*"
          ], 
          "condition": {
              "time": {
                  "dateGreaterThan": "2016-09-07T00:00:00Z"
              }
          }, 
          "action": {
              "name": "DeleteObject"
          }
      },
      {
          "id": "sample-rule-transition-prefix", 
          "status": "enabled", 
          "resource": [
              "samplebucket/prefix2/*"
          ], 
          "condition": {
              "time": {
                  "dateGreaterThan": "$(lastModified)+P30D"
              }
          }, 
          "action": {
              "name": "Transition",
              "storageClass": "STANDARD_IA"
          }
      },
      {
          "id": "sample-rule-abort-multiupload-prefix", 
          "status": "enabled", 
          "resource": [
              "samplebucket/prefix3/*"
          ], 
          "condition": {
              "time": {
                  "dateGreaterThan": "$(lastModified)+P5D"
              }
          }, 
          "action": {
              "name": "AbortMultipartUpload"
          }
      }
  ]
  }

每条规则由id、status、resource、condition和action组成，详细解释参见下表。

规则项	描述	是否必填	备注
id	规则的标识符。	可选	同一个bucket内规则id必须唯一，不能重复。如果用户不填系统会自动帮用户生成一个。
status	规则的状态。	必填	取值为enabled或disabled，当规则处于disabled时规则不生效。
resource	规则对哪些资源生效。	必填	举例：对samplebucket里以prefix/为前缀的Object生效：samplebucket/prefix/*；对samplebucket里所有Object生效：samplebucket/*。
condition	规则依赖的条件。	必填	目前只支持time形式。
+time	时间限制条件。	必填	通过定义的dateGreaterThan实现。
++dateGreaterThan	描述时间关系。	必填	支持绝对时间date和相对时间days。绝对时间date格式为yyyy-mm-ddThh:mm:ssZ，eg. 2016-09-07T00:00:00Z。绝对时间为UTC时间, 必须以00:00:00(UTC 0点)结尾；相对时间days的描述遵循ISO8601, 支持的最小时间粒度为天，如:$(lastModified)+P7D表示的时间为object的last-modified之后7天。
action	对resource执行的操作动作。	必填	-
+name	执行的操作名称。	必填	取值为Transition、DeleteObject、AbortMultipartUpload。
+storageClass	Object的存储类型	可选	action为Transition时可以设定，取值为STANDARD_IA，表示从标准类型转为低频存储类型, 取值为COLD，表示从标准类型转为冷存储类型,取值为ARCHIVE表示从标准类型转为归档存储类型。

action

BOS支持Transition、DeleteObject、AbortMultipartUpload三种操作，三种动作的详细解释如下：

操作	描述	备注
Transition	将resource转换存储类型。	- 文件在标准存储中存储时长必须大于7天才会被转为低频存储。因为文件创建后的7天通常为频繁访问期，转换成低频可能会增加成本。文件在低频存储中保存时间大于30天才会被转为冷存储, 因为在低频存储可能还会有低频度的访问需求, 如果转换成冷存储可能会增加成本 - 通过生命周期转成低频时，文件的last-modified不会更改。
DeleteObject	将resource删除。	根据设定的规则删除resource。低频存储有30天的最低保存时间，所以用户如果创建规则去删除一个存储时长不到30天的低频文件，会产生额外花费。
AbortMultipartUpload	清除一段时间内还没有完成的三步上传。	需要设置放弃分块上传的时间days。

dateGreaterThan

BOS支持绝对时间date和相对时间days两种形式的dateGreaterThan设置，注意事项如下：

dateGreaterThan项	描述	支持动作	备注
days	数据达到lastModified+days后执行操作。	支持transition、expiration、abortMultipartUpload三种操作。	- 使用days进行生命周期管理的文件，其操作执行时间是：文件的Last-modified加上days，再取整到下一个UTC午夜零点。例如，一个Object的最后更新时间是UTC的2014年4月12日上午1点，相匹配的规则定义的天数是3天，执行操作的时间是UTC 2014年4月16日0点整。 - 如果之后文件的last-modified发生修改，如meta更新、数据overwrite，那么操作的执行时间也会随之变化。
date	在指定日期执行操作。	支持transition和expiration两种操作。	- 如果指定date，date必须是UTC午夜零点，并且符合形如2014-01-01T00:00:00.000Z的ISO8601格式。 - date规则只会对Last-modified时间早于或等于date的文件生效。 - date规则会在当前时间>=date执行。 - 当date和“标准存储存够7天”冲突时，优先“标准存储存够7天”。

说明：

• 每条规则里只能包含一个action。
• 每个resource每种action最多只能有一条规则，例如bucket/prefix1/*不能有两条transition规则，但可以有一条transition规则加一条expiration规则。
• 规则中如果以prefix定义的作用范围有包含关系，对于被包含的prefix以最小的作用范围定义的动作为准。如规则1定义prefix是 p1/p1/ 的Object 10天后delete，规则2定义prefix是 p1/p1/p1/的Object 15天后delete，规则1的prefix包含规则2的prefix，对于prefix为 p1/p1/p1/ 的Object执行15天后delete，对于p1/p1/中除了p1/p1/p1/之外的Object执行10天后delete动作。
• 如果使用date作为Condition时，如“folder/”为prefix的文件，在30天后转低频，并于2016.8.17号删除。系统会依据规则计算出每个文件执行相应操作的时间，并对时间进行比对。如果文件同一天执行transition和expiration，则直接删除；如果文件删除时间早于转低频时间，也直接删除。