Azure Event Hub Throttled requests指标含义及消息丢失咨询

你在Azure门户监控中观测到的限流指标截图如下：

针对你提出的三个问题，具体说明如下：

Throttled requests的具体含义 #

该指标是Event Hub的容量保护类指标，统计的是服务端触发限流机制时拦截的请求总数：当当前命名空间或指定事件中心的实际负载（包含每秒入口/出口事件数、每秒入口/出口带宽）超出预配置的吞吐量单位（TU）、处理单位（PU）对应的容量阈值时，服务端就会触发限流，把超出容量承载能力的请求计入这个指标。

“请求被拒绝”的实际指代 #

这里的“拒绝”是临时的可重试拦截，不是永久丢弃请求：

• 服务端收到超出容量的请求时，不会处理请求内的消息读写逻辑，会直接给客户端返回明确的可重试错误：使用Kafka协议对接时返回PolicyViolationException，使用Event Hub原生SDK时返回ServerBusyException。
• 符合规范的客户端（包括官方Kafka客户端、Event Hub SDK）收到该类错误后，不会直接判定请求失败，会按照默认配置的指数退避策略等待一段时间后自动重发请求。这也是你核对所有Topic消息总数和预期完全一致、没有发现消息丢失的核心原因。

限流现象是否会导致生产者/消费者丢消息 #

默认配置场景下不会导致消息丢失，只有客户端配置不当时才可能出现异常：

• 常规场景：客户端保留默认的重试策略，被限流的请求会自动重试直到成功，消息会正常写入服务端、或者被消费者正常拉取，不会出现丢失。你当前的观测结果就属于这类正常情况。
• 异常场景：
  • 生产者手动关闭重试逻辑、或设置的重试次数为0/重试超时时间过短，被限流后直接向上层抛出错误，业务侧未做消息兜底存储的，会导致这部分待发送消息没有成功写入Event Hub。
  • 消费者拉取消息时触发限流，未正确处理重试逻辑就提前提交消费位点，会导致未实际拉取处理的消息被跳过，出现业务侧感知的“消息丢失”，这类问题属于客户端配置错误，并非限流机制本身导致的必然结果。

如果Throttled requests指标持续走高，说明当前预配的容量已经接近业务负载瓶颈，可以通过扩容TU/PU、调整客户端批量发送/拉取的批次大小、错开业务峰值发送时间等方式降低限流触发频率，减少请求重试带来的业务延迟。

内容的提问来源于stack exchange，提问作者Hayi