概述

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

文件生命周期管理方式

• 为了使数据管理更加便捷与智能，我们在保持【基础生命周期管理】（原生命周期管理）的基础上，又支持了【智能分层】，智能分层不仅可根据文件访问频次进行自动沉降，也可根据文件的访问情况进行智能冷热转化，自动升级至标准或低频存储，该功能提供了数据存储的成本与读写性能最优解决方案。
• 在基础生命周期中在基础基于前缀进行细化管理的能力上，又扩展支持设置对象标签功能(Tag)、目录排除(Not)、文件大小过滤(Filesize)、对象多版本的生命周期管理功能，可细化生命周期操作粒度。

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

功能说明

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

智能分层

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

智能分层注意事项

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

基础生命周期

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

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

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

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

从规则配置上划分，基础生命周期管理支持简单与复杂模式

• 简单模式：定义规则中仅还有指定生效文件范围设置仅配置前缀或存储桶全部文件（不包含多版本对象）；
• 复杂模式：定义规则中包含指定生效文件范围设置包含对象标签、排除某些文件、指定文件大小、对象历史版本中的任意一种配置。

复杂生命周期规则管理支持功能

• 支持设置对象标签，支持指定标签沉降删除Object。
• 支持设置目录排除，排除目录外的Object以及指定对象标签。
• 支持设置文件大小，支持对指定文件大小范围内的object进行沉降删除。
• 设置多版本生命周期， 支持对历史版本进行删除。

特别提示

存储桶生命周期管理规则复杂和简单模式，表现在对文件的转化与删除的执行规则的区别。

• 简单模式：对冲突的多条简单规则会按照“精细化执行”的逻辑，例如：规则 1：当设置 a/b/ 目录下文件创建满 180 天删除；规则 2： a/b/c 目录下文件创建满365 天删除,执行结果为a/b/c/1.txt 文件会在创建满365 后执行删除，而a/b/2.txt 则会在创建满180 后执行删除。
• 复杂模式：对冲突的多条复杂规则会按照“全局最优执行”的逻辑，且删除优先。例如规则 1：当设置 a/b/ 目录下文件（未配置历史版本）创建满 180 天删除；规则 2： a/b/ 目录下文件配置 365 天删除，并且排除 a/b/test目录,执行结果为a/b/c/1.txt 文件会在创建满180 天后执行删除，a/b/test/2.txt 也会在 180 天后删除。
• 特别提示存储桶中若创建一条复杂规则，则存储桶生命周期管理整体应用复杂规则执行

基础生命周期注意事项

通用注意事项

• 每个 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 请求费用，该请求费用包含在写请求费用中。

包含复杂生命周期规则注意事项

复杂生命周期规则注意事项

• 多版本生命周期的历史版本的判定时间是成为历史版本的时间，而不是其元数据的修改时间。
• 多版本的生命周期不支持归档类型
• tag的规则设置: 每个规则最多有10个对象标签，每个key长度小于等于128， value长度小于等于256。
• 每个rule下只有1个排除目录, 开启Not选项时，前缀和标签必须至少存在一项，即同时设置前缀和标签或者只设置前缀或标签，Not中的前缀或标签只有一个；排除前缀必须位于设置前缀之下，并和前缀的结构形式一样，例如前缀是 bucket/prefix , not prefix可以是bucket/prefix1
• 指定最小文件指定生命周期规则作用的最小文件大小，最小文件大小要求大于等于0字节，小于5TB。
• 指定最大文件指定生命周期规则作用的最大文件大小，最大文件大小要求大于0字节，小于等于5TB。
• 基础生命周期语义和复杂生命周期语义有一定的区别， 对于基础生命周期语义， 按照的是最长前缀的原则， 如果命中最长前缀，那么就不会去寻找其他规则。 复杂生命周期语义会寻找全局最优规则， 寻找符合prefix, not, filesize, tag的规则下最早执行的规则。

配置方式

• 通过 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天未完成的三步上传。

  Plain Text 复制

  1 {
  2"rule": [
  3    {
  4        "id": "sample-rule-delete-prefix", 
  5        "status": "enabled", 
  6        "resource": [
  7            "samplebucket/prefix1/*"
  8        ], 
  9        "condition": {
  10            "time": {
  11                "dateGreaterThan": "2016-09-07T00:00:00Z"
  12            }
  13        }, 
  14        "action": {
  15            "name": "DeleteObject"
  16        }
  17    },
  18    {
  19        "id": "sample-rule-transition-prefix", 
  20        "status": "enabled", 
  21        "resource": [
  22            "samplebucket/prefix2/*"
  23        ], 
  24        "condition": {
  25            "time": {
  26                "dateGreaterThan": "$(lastModified)+P30D"
  27            }
  28        }, 
  29        "action": {
  30            "name": "Transition",
  31            "storageClass": "STANDARD_IA"
  32        }
  33    },
  34    {
  35        "id": "sample-rule-abort-multiupload-prefix", 
  36        "status": "enabled", 
  37        "resource": [
  38            "samplebucket/prefix3/*"
  39        ], 
  40        "condition": {
  41            "time": {
  42                "dateGreaterThan": "$(lastModified)+P5D"
  43            }
  44        }, 
  45        "action": {
  46            "name": "AbortMultipartUpload"
  47        }
  48    }
  49]
  50}

以下是一个复杂生命周期的配置规则, 包含两个配置

• 最新版本为在prefix/目录下且不在prefix/prefix1/下，tag为'key1':'value1'或者'key2':'value2' 并且tag不包含'key3':'value3'的, 同时满足大小为1024字节到2048字节的object， 并且object在超过3天没有修改的object会被删除，同时这个目录下最新版本的object如果只有删除标记将会在下一轮的生命周期中被清除。
• 历史版本为在整个目录下，tag为'key1':'value1'或者'key2':'value2'的成为历史版本超过5天的object会被删除。

1{
2  "rule": [{
3  "id": "rule-id",
4  "status": "enabled",
5  "ExpiredObjectDeleteMarker" :"true",
6  "resource": [
7      "bucket/prefix/*"
8  ],
9  "condition": {
10      "time": {
11          "dateGreaterThan": "$(lastModified)+P3D"
12      },
13      "objectSize":{
14          "minSize":1024,
15          "maxSize":2048
16      },
17      "tag": {
18          "key1":"value1", 
19          "key2":"value2"
20      } 
21  },
22  "action": {
23      "name": "DeleteObject"
24  },
25  "not":{ // 一个规则只有一个not prefix+ not tag 其中prefix和tag 必须存在一项
26      "resource": "bucket/prefix/prefix1*",
27      "tag": {"key3":"value3"}
28  }
29 },{
30  "id": "rule-id2",
31  "status": "enabled",
32  "resource": [
33      "bucket/*"
34  ],
35  "condition": {
36      "time": {
37          "dateGreaterThan": "$(lastModified)+P5D"
38      },
39      "tag": {
40          "key1":"value1", 
41          "key2":"value2"
42      } 
43  },
44  "action": {
45      "name": "NonCurrentVersionDeleteObject"
46  }
47  
48 }]
49}

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

action

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

dateGreaterThan

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

说明：

• 每条规则里只能包含一个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，则直接删除；如果文件删除时间早于转低频时间，也直接删除。
• 复杂的生命周期规则需要注意的是， 和基础生命周期规则不同，对于被包含的prefix语义，按照时间最小原则执行，如规则1 定义prefix是p1/p1/ 的object 10天后delete， 规则2定义的prefix是p1/p1/p1/的object是13天后删除， 那么会先执行规则1的删除。如果想实现规则2的prefix是13天后删除， 需要在规则1中加入not p1/p1/p1/， 将规则2的目录排除。