Azure Relay与Azure Fluid Relay限流阈值及规则咨询

一、Azure Relay 限流阈值 #

Azure Relay的限流阈值按服务层级和命名空间维度划分：

• Basic层：
  • 单命名空间最大连接数：1000
  • 单命名空间每秒消息处理量（TPS）：1000
  • 单命名空间每秒数据吞吐量：10MB
• Standard层：
  • 单命名空间最大连接数：10000
  • 单命名空间每秒消息处理量（TPS）：10000
  • 单命名空间每秒数据吞吐量：100MB

超出上述任一阈值，服务会返回429限流错误。

二、Azure Fluid Relay 限流定义 #

Azure Fluid Relay的限流规则围绕资源使用场景细分：

• 单Fluid容器（Container）的操作频率限制：包括文档创建/更新、操作提交等动作的速率上限
• 单个用户针对单容器的请求速率限制
• 租户级Fluid资源总使用量限制
  不同服务层级对应不同阈值，核心目标是避免单个资源（容器/用户）过度占用服务能力，保障多租户环境稳定。

三、限流维度与应用隔离情况 #

限流维度 #

• Azure Relay：以命名空间为核心限流维度，同一命名空间下所有应用共享阈值；租户层面存在总配额，但命名空间内的限流触发优先级更高。
• Azure Fluid Relay：结合租户、容器、用户三重维度，租户级有总配额，容器和用户级有细分速率限制。

应用隔离 #

• Azure Relay：不同命名空间的应用完全隔离，单个应用的限流不会影响其他命名空间的应用；但同一命名空间内的多个应用共享阈值，若某一应用过度消耗资源，会导致整个命名空间触发429错误。
• Azure Fluid Relay：同一租户下的不同容器相互隔离，单个容器限流不会波及其他容器；仅当租户级总配额耗尽时，才会影响该租户下所有Fluid应用。

四、低负载下触发429的可能原因 #

结合你提供的报错信息（"Throttling count exceeded by 1066"），低负载下触发限流的常见原因包括：

• 应用侧存在高频重复请求：比如WebSocket连接频繁重连、重复提交相同操作，短时间内累计请求量远超阈值
• 命名空间层级配置过低：若使用Basic层，本身阈值有限，少量并发请求即可触发限流
• 连接管理不当：未正确关闭闲置WebSocket连接，导致连接数持续累积达到上限
• 服务临时限流：Azure Relay偶尔会因后台维护或资源调度触发临时限流，此类情况通常会自动恢复

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