Azure Service Bus核心技术问题咨询：容量阈值行为、转发死信异常及过滤器评估失败场景

我来帮你逐个梳理这些Azure Service Bus的核心问题，结合实际使用经验给你解答：

问题1：队列/主题达到最大容量后发送消息会怎样？ #

当队列或主题的总容量（活跃消息+死信消息+待转发/转移消息+定时消息+转移死信消息）达到配置的最大阈值时，后续发送消息的请求会被直接拒绝，Service Bus会返回**QuotaExceeded**错误（对应HTTP状态码403，SDK中会抛出对应的异常，比如.NET里的MessagingEntityQuotaExceededException）。

这种情况下，你需要先清理现有消息（比如处理活跃消息、删除死信队列中的消息），或者手动调整队列/主题的容量配额，才能恢复接收新消息。另外如果是使用分区实体，每个分区的容量是总配额除以分区数，单个分区满额也会导致该分区无法接收新消息。

问题2：订阅转发到已停用主题，死信计数而非转发死信计数增加的原因 #

你遇到的这个情况是符合Service Bus的设计逻辑的：
当你配置订阅转发到另一个主题，但目标主题处于**已停用（Disabled）**状态时，这属于明确的永久性无法投递场景，Service Bus会将消息直接放入原订阅的死信队列，而非转发死信队列。

转发死信队列（Transfer Dead Letter）针对的是转发过程中的暂时性问题：比如目标主题暂时不可达、权限配置错误、目标主题容量不足等可恢复的情况。而如果目标主题是被主动停用的，系统判定这是无法通过重试解决的问题，因此直接将消息移入原订阅的死信队列。

建议你确认目标主题的状态是否确实为“停用”，如果是临时维护需要，可以先启用目标主题，再处理死信队列中的消息。

问题3：订阅过滤器评估失败的常见场景 #

订阅过滤器评估失败通常发生在以下几种情况：

• 过滤器语法错误：比如SQL过滤器的语法不符合Service Bus的SQL规则，例如引用不存在的消息属性、错误使用SQL函数（比如对非字符串字段使用CONTAINS）、缺少必要的关键字等。
• 数据类型不匹配：过滤器中进行比较的两个值类型不兼容，比如将数值类型的消息属性和字符串常量比较（WHERE Age = '30'），或者对非布尔类型的属性使用IS TRUE判断。
• 未处理空值场景：过滤器引用了一个不存在的消息属性，且没有处理空值的逻辑（比如WHERE NonExistentProperty = 'test'），此时评估会直接失败。
• 表达式超出限制：过滤器的表达式长度过长、嵌套层级过深，超过了Service Bus对过滤器的限制（比如SQL过滤器表达式最多允许1024个字符）。
• 消息属性格式无效：消息属性的值是无法被过滤器解析的格式，比如将二进制数据直接用于SQL过滤器的比较逻辑。

备注：内容来源于stack exchange，提问作者Learner