Azure Blob 存储 将数据分布到各个分区，以提供可扩展的性能。 当流量集中在单个分区时，该分区可能成为瓶颈，这种情况称为 热分区。 本文解释了什么是热分区，如何通过 Azure Monitor 指标和资源日志识别它们，以及你可以采取哪些措施更均匀地分配负载并减少限速错误。
理解热分区
Azure Blob 存储 会自动将数据分拆到各个分区，以实现性能和吞吐量的扩展。 当单个分区接收的流量明显超过其他分区时，它就成为 热分区。 热分区是指大量读、写或更新请求同时到达同一分区，限制了服务有效平衡工作负载的能力。 因此，请求会经历更高的延迟、限速和超时错误，直到工作负载重新分配或访问模式得到优化。 将流量集中在一小部分数据上而非分散请求到多个分区的分区或命名方案，常常会导致热分区。
热分区的症状与影响
当存储分区变热时，它无法再高效地处理请求。 随着分区接近可扩展性限制，Azure 存储 开始限速请求，以保护服务并维护其他工作负载的可靠性。 客户端应用会增加延迟、吞吐量降低和瞬态请求失败。
热分断的常见症状包括：
- HTTP 503（服务器忙碌）响应表示分区暂时无法处理更多请求。
- 当请求因分区负载过重而长时间未完成时，会返回 HTTP 500（操作超时） 响应。
- 即使请求最终成功，延迟也会增加。
- 自动客户端重试，如果多个客户端同时重试，会进一步增加流量并延长性能问题。
- 吞吐量降低，即尽管账户整体存储容量充足，应用每秒处理的操作数仍低于预期。
热分区通常是由于访问模式将流量集中在单个分区引起的。 常见的例子包括按顺序命名的 Blob、只追加的工作负载，以及会将过多流量发送到单个分区的分区键设计。 当工作负载分布不均匀时，受影响的分区会比存储账户的其他部分更早达到极限，从而造成瓶颈，影响应用性能。
对于许多应用来说，热分区的第一个迹象是延迟上升、重试率增加以及在高需求期内503或500错误数量增加的组合。
通过使用 Azure Monitor 指标和资源日志检测限速错误
当工作负载超过存储账户或分区的可扩展性目标时，Azure 存储会限制请求。 你通常会看到限速表现为HTTP 503（服务器忙） 或 500（操作超时） 响应。 Azure 存储客户端库经常会自动重试被限速的请求，因此监控对于在限速严重影响应用性能之前发现它至关重要。
使用 Azure Monitor 指标识别节流错误
要检测限流，请分析 Azure Monitor 中存储帐户的指标。 事务指标结合响应类型维度，可以直观查看存储请求的结果，并帮助你识别与限速相关的故障。
用于识别限流的指标
以下 Azure Monitor 指标在调查限速时非常有用：
| Metric | Purpose |
|---|---|
| 交易 | 衡量存储服务处理的请求数量。 使用 ResponseType 维度来识别被限速的请求。 |
| 可用性 | 显示成功请求的百分比。 可用性下降可能意味着发生了节流或其他请求失败。 |
| 成功 E2E 延迟 | 衡量端到端请求延迟，包括网络和客户端处理。 增多可能表明重试是由限制速率引起的。 |
| 成功服务器延迟 | 衡量存储服务处理请求所需的时间。 将该指标与端对端延迟进行比较，有助于区分服务端延迟与客户端重转延迟。 |
一种常见的节流模式通常表现为延迟增加，同时伴随与节流相关的响应类型增多以及可用性下降。
使用 ResponseType 维度来识别限速
ResponseType 维度是识别 Azure Monitor 指标中限速条件的主要工具。 相关价值观包括：
| ResponseType 值 | 说明 |
|---|---|
| ServerBusyError | 存储服务返回HTTP 503是因为超出了扩展性目标。 |
| ClientThrottlingError（客户端节流错误） | 请求在到达存储服务之前就被限流了。 |
| ClientAccountRequestThrottlingError | 账户级请求速率限制被超越。 |
| ClientAccountBandwidthThrottlingError（客户端账户带宽节流错误） | 账户带宽已超出限制。 |
| 限流成功 | 该请求最初被限速，但经过多次重试后最终成功。 |
跟踪这些数值随时间变化，有助于你识别暂时的限速峰值以及持续的可扩展性问题。
利用维度精确定位限流的来源
Azure Monitor 的度量维度可以帮助隔离导致限速的工作量：
| Dimension | Purpose |
|---|---|
| ResponseType | 识别具体的限速或错误状况。 |
| ApiName | 识别出现节流的操作，如 PutBlob、 GetBlob或 ListBlobs。 |
| GeoType | 区分地理冗余存储账户中主端和备端的流量。 |
| Authentication | 帮助判断限速是否与某种认证方法相关。 |
例如，如果限制主要发生在 PutBlob 操作上，则该工作负载可能是写入密集型的。 如果某个特定API操作显示出较高的限速率，优化工作可以专注于该操作，而非整个应用。
分析 Azure Monitor 资源日志
虽然指标能识别限速的存在，但 Azure Monitor 资源日志则提供请求级别的详细信息，有助于诊断根本原因。 资源日志记录成功和失败的请求，包括限速、超时、授权以及网络相关错误。
对于 Azure Blob 存储，记录可在资源日志发送到 Log Analytics 工作区后，在 StorageBlobLogs 表中获得。
查询限速事件的资源日志
在运行这些查询之前，确保资源日志已发送到Log Analytics工作区。
使用 Kusto 查询语言（KQL）来识别返回常见限速相关状态码的请求：
StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc
通过按操作、认证类型、呼叫者IP地址或应用身份分组结果来扩展此查询，以识别产生限速请求的工作负载。 资源日志对于判断限速是否集中在特定应用、操作或时间段中尤其有用。
节流警报条件
为以下项创建 Azure Monitor 警报：
- ServerBusyError事务持续发生。
- 与节流相关的 ResponseType 值有所增加。
- 可用性指标降至可接受阈值以下。
- 与限流事件相关的延迟增加
- 请求量突然增加，接近存储可扩展性极限。
推荐的监控工作流程
- 监控 交易 指标，并按 响应类型划分结果。
- 留意限流相关的响应类型是否有所增加，例如 ServerBusyError 和 ClientThrottlingError。
- 使用 ApiName 维度来识别受影响的操作。
- 将限速事件与 可用性变化、 成功端对端延迟和 成功服务器延迟的变化关联起来。
- 使用Azure Monitor资源日志来确定哪些请求、操作或应用产生了流量限速。
- 配置警报，确保限速问题能在影响用户之前被检测到。
通过结合 Azure Monitor 的指标、维度和资源日志，您可以快速检测限速状况，识别过高需求源，并在应用性能下降前采取纠正措施。
缓解热分区
为防止热分区，应将请求均匀分布到各个分区，并确保应用程序在受到限制时能够做出适当响应。
使用高效的分区和命名方案
设计分区键、blob 名称及其他标识符，使请求分布在多个分区之间。 避免采用顺序命名模式或仅追加式命名模式，以免将大多数请求定向到同一分区。 参见 优化 blob 分区和命名方案。
重试时使用指数退避
如果请求被限速并返回 503（服务器忙） 或 500（操作超时） 错误，请使用指数退选策略重新尝试请求。 这种方法减轻了受影响分区的压力，并给 Azure 存储 时间重新平衡负载或从临时需求激增中恢复。
指数回溯重试行为对于通过使用 Azure 存储 客户端库、SDK 或 REST API 访问 Azure 存储 的自定义应用最为相关。 许多Microsoft 服务、托管应用和第三方客户端已经实现了合适的重试逻辑，所以你可能不需要额外配置。 如果你正在开发自定义应用，确保重试策略已启用并按照 Azure 存储 最佳实践配置。 查看下列任何文章：
避免请求量突然激增
在引入新工作负载、运行性能测试或处理大量数据时，应逐步提高请求速率，而非立即产生峰值流量。 Azure 存储 会根据需求变化自动对分区进行负载均衡，但流量突发激增可能会暂时压垮分区，导致限速，直到服务有机会调整。
后续步骤
有关详细实施指导，请参见：