Azure Blob 存储常见问题解答

平台每天运行一次生命周期策略。 配置策略后，该策略最长可能需要 24 小时才能生效。 策略生效后，运行操作所需的时间可能会因存储帐户的大小和执行的操作而异。

已更新的策略最多需要 24 小时才能生效。 策略生效后，运行操作所需的时间因存储帐户的大小和执行的操作而异。 如果更新是禁用或删除规则，并且使用了 enableAutoTierToHotFromCool，则仍将发生自动分层到热存储层的情况。 例如，根据上次访问设置一个包含 enableAutoTierToHotFromCool 的规则。 如果规则处于禁用或删除状态，并且 Blob 当前处于冷存储层或寒存储层并随后被访问，则该 Blob 将会移动回热存储层，因为该规则适用于对生命周期管理外部的访问。 如果生命周期管理规则被禁用或删除，则 Blob 不会从热存储层移动到冷存储层或寒存储层。 阻止 autoTierToHotFromCool 的唯一方法就是关闭上次访问时间跟踪。

根据存储帐户中对象的大小和数量，可能需要多次运行才能处理完所有对象。 你还可以检查存储资源日志，以查看生命周期管理策略是否正在执行操作。

检查存储帐户上是否启用了数据保护功能，例如软删除或版本控制。 即使策略正在删除 Blob，这些 Blob 可能仍以软删除状态或旧版本存在，具体取决于这些功能的配置方式。

如果存在对存储帐户有效的生命周期管理策略，则通过更改 blob 的层来解除 blob 的冻结可能会导致生命周期策略将 blob 移回存档层的情况。 如果上次修改时间、创建时间或上次访问时间超出为策略设置的阈值，则可能会发生这种情况。 有三种方法可以阻止这种情况发生：

• 将 daysAfterLastTierChangeGreaterThan 条件添加到策略的 tierToArchive 操作。 此条件仅适用于上次修改时间。 请参阅使用生命周期管理策略存档 Blob。

• 暂时禁用影响此 Blob 的规则可防止该 Blob 再次存档。 可以安全地将 Blob 移回到存档层时，重新启用该规则即可。

• 如果 Blob 需要永久保留在热存储层、冷存储层或寒存储层中，请将 Blob 复制到生命周期管理策略未生效的另一个位置。

策略的 Blob 前缀匹配字段是完整或部分 Blob 路径，用于匹配要将策略操作应用到的 Blob。 路径必须以容器名称开头。 如果未指定前缀匹配，则策略将应用到存储帐户中的所有 Blob。 前缀匹配字符串的格式为 [container name]/[blob name]。
对于前缀匹配字符串，请注意以下几点：

• 前缀匹配字符串（如 container1/） 适用于名为 container1 的容器中的所有 blob。 container1 的前缀匹配字符串（不带尾部正斜杠字符 (/)）适用于容器名称以字符串 container1 开头的所有容器中的所有 blob。 此前缀将匹配名为 container11、container1234、container1ab 之类的容器。
• container1/sub1/ 前缀匹配字符串适用于名为 container1 的容器中以字符串 sub1/ 开头的所有 blob。 例如，前缀将匹配名为 container1/sub1/test.txt 或 container1/sub1/sub2/test.txt 的 blob。
• 星号字符 * 是 blob 名称中的有效字符。 如果在前缀中使用星号字符，则前缀将匹配名称中带有星号的 blob。 星号不会起到通配符的作用。
• 问号字符 ? 是 blob 名称中的有效字符。 如果在前缀中使用问号字符，则前缀将匹配名称中带有问号的 blob。 问号不会起到通配符的作用。
• 前缀匹配只考虑正 (=) 逻辑比较。 会忽略否定 (!=) 逻辑比较。
• 前缀匹配将区分大小写。

很抱歉，无法跟踪策略将执行的时间，因为它是一个后台计划过程。 但是，平台将每天运行一次策略。

每日盘存规则设计为每天运行一次。 此外，每星期日还安排了一个每周盘存规则。

虽然我们努力提供一致的体验，但我们不能保证每次运行的确切执行时间。 盘存规则的执行时间可能会有所变化。 例如，如果今天的策略安排在上午 12:05，则第二天它可能会在上午 12:07、上午 12:15 或任何其他时间开始。

Blob 清单报表会生成三种类型的文件。 请参阅清单文件。 使用 Blob 清单的现有客户可能会看到清单文件数的变化，从一个文件更改为多个文件。 目前，我们已经有了提供文件列表的清单文件。 此行为保持不变，所以这些文件会列在清单文件中。

实施此更改是为了增强 Blob 清单性能，尤其是对于包含超过 500 万个对象的大型存储帐户。 现在，结果会并行写入多个文件，消除了使用单个清单文件的瓶颈。 客户反馈引导了这一更改，因为客户报告在打开和使用过大的单个清单文件时遇到了困难。

作为用户，此更改会对 Blob 清单运行体验产生积极的影响。 它有望提高性能并减少总体运行时间。 但是，若要充分利用此改进，你必须确保代码已更新，这样才能处理多个结果文件，不然只能处理一个结果文件。 此调整使代码与新方法保持一致，并优化了清单数据的处理。

否，现有数据不受影响。 只有新的 Blob 清单结果有多个清单文件。

否，更改是无缝进行的。

你需要进行的操作取决于你当前处理 Blob 清单结果的方式：

• 如果你当前的处理方式是针对单个清单结果文件的，则需要修改代码以适应多个清单结果文件的情况。

• 但是，如果你当前的处理方式涉及从清单文件读取结果文件列表，则无需对处理结果的方式进行任何更改。 现有方法会继续与更新的功能无缝配合。

不建议这样做，但这是可行的。 请通过你的支持渠道请求关闭此功能。

请咨询你的当前帐户团队和支持渠道。

此更改将从 2023 年 9 月 1 日开始逐步推出。

不是。 Azure 计算支持磁盘上的指标。 有关详细信息，请参阅 托管和非托管磁盘的每个磁盘指标。

某些 Azure 指标图表（例如显示可用性和延迟数据的图表）使用虚线表示两个已知时间粒度数据点之间缺失的值（也称为 null 值）。 例如，如果在时间选择器中选取了 1 minute 时间粒度，但指标在 07:26、07:27、07:29 和 07:30 报告，则虚线将连接 07:27 和 07:29，因为这两个数据点之间存在一分钟间隔。 实线连接所有其他数据点。 当指标使用计数和求和聚合时，虚线将下降到零。 对于 avg、min 或 max 聚合，虚线连接两个最近的已知数据点。 此外，当图表最右侧或最左侧缺少数据时，虚线将朝缺失数据点的方向延长。

可以基于 Azure 资源运行状况服务配置资源运行状况警报，以跟踪存储帐户的可用性。 如果帐户上没有事务，则警报会根据存储帐户所在的存储群集的运行状况进行报告。

分析日志包含所有读取、写入、列出和删除操作的记录，以及对所有操作的成功和失败请求的记录。 分析日志的记录原则是“尽量记录”，不保证记录顺序。

更改源解决方案提供对帐户成功执行的变动或更改操作（例如创建、修改和删除 Blob）的事务日志。 更改源保证按照每个 Blob 的成功更改顺序记录和显示所有事件，因此你无需从大量的读取操作或失败请求中筛选出干扰性的信息。 更改源在本质上是为需要特定保证的应用程序开发而设计和优化的。

可以利用这两项功能，因为更改源和 Blob 存储事件以相同的交付可靠性保证提供相同的信息，其主要差别在于事件记录的延迟、排序和存储。 在更改后的几分钟内，更改源就会将记录发布到日志，同时还保证每个 Blob 的更改操作顺序。 存储事件将实时推送，可能不会排序。 更改源事件根据你自己定义的保留期，以只读的稳定日志形式持久存储在存储帐户中，而存储事件由事件处理程序即时使用，除非你显式存储这些事件。 借助更改源，任意数量的应用程序都可以通过 Blob API 或 SDK 在方便的时间使用日志。

是的。 存储帐户网络安全规则（包括基于 IP 的和 VNET 防火墙）支持静态网站终结点，并且可用于保护网站。

不是。 静态网站仅支持对 $web 容器中文件的匿名公共读取访问。

如果使用错误的大小写引用文件名，则会发生 404 错误。 例如，Index.html 而非 index.html。 静态网站的 URL 中的文件名和扩展名区分大小写，即使通过 HTTP 提供也是如此。

在 Azure 门户中，打开帐户的静态网站配置页，并查找在“索引文档名称”字段中设置的名称和扩展名。 确保此名称与位于存储帐户的 $web 容器中的文件的名称完全相同。 静态网站的 URL 中的文件名和扩展名区分大小写，即使通过 HTTP 提供也是如此。

否，如果需要在 Blob 数据内搜索，请使用查询加速或 Azure 搜索。

Blob 索引标记仅支持字符串数据类型，且查询按字典顺序返回结果。 对于数字，是零填充数字。 对于日期和时间，则存储为符合 ISO 8601 的格式。

否，资源管理器标记可帮助组织控制平面资源，例如订阅、资源组和存储帐户。 而索引标记在数据平面提供 Blob 管理和发现功能。

存储容量按一个月内每天的平均数据存储量 (GB) 计费。 例如，如果前半个月稳定地使用了 10 GB 的存储，而后半个月未使用任何存储，则按 5 GB 平均存储使用量计费。

后续步骤

你可以访问以下链接了解有关 Azure Blob 存储的详细信息：

• Azure 存储简介
• 什么是 Azure Blob 存储