如何仅从Azure Service Bus队列中接收指定correlation id的消息

以下方案均不需要创建额外的Azure Service Bus（ASB）资源，不需要调整现有队列拓扑，实现成本远低于会话和topic订阅过滤器模式。

方案1：轻量消息匹配模式（适用于QPS<1000的中低并发场景） #

• 要求应用B发送回复消息时，将correlation id直接填入ASB消息的原生CorrelationId系统属性，无需额外自定义属性。
• 应用A收到REST请求生成唯一correlation id后，基于目标队列初始化ServiceBusReceiver实例，采用Peek-Lock模式拉取消息：
  • 单次拉取少量消息（推荐5~10条，可根据实际并发量调整），遍历匹配消息的CorrelationId与当前请求的id
  • 匹配到目标消息后调用Complete方法确认消息，基于消息内容生成REST响应返回给调用方
  • 其余不匹配的消息直接调用Abandon方法释放锁，消息到期后会自动回到队列供其他请求实例匹配
• 该方案无任何ASB侧额外配置，代码改动量极小，仅存在少量非目标消息的临时加解锁开销，中低并发场景下无性能压力。

方案2：单消费者+本地缓存分发模式（适用于高并发场景） #

• 在应用A中启动一个单例的后台消息接收服务，持续从队列拉取所有回复消息，将消息按照CorrelationId为key写入本地内存缓存（可使用ConcurrentDictionary实现），缓存过期时间设置为比REST请求超时时间长30s即可。
• 应用A的每个REST请求处理线程生成correlation id后，仅需轮询等待本地缓存中出现对应key的消息，拿到消息后删除缓存key即可生成响应返回。
• 若应用A为多实例部署，可调整逻辑：应用A发请求给B时额外携带自身实例ID，应用B回复时将实例ID写入ASB消息的Label属性，后台接收服务拉取到消息后先按Label路由到对应实例的缓存即可，也可直接替换为分布式缓存简化多实例适配逻辑。
• 该方案仅存在一个队列消费者，无多余的消息加解锁开销，性能远高于方案1，且无需维护ASB侧的任何额外资源。

方案优势对比 #

• 对比会话模式：无需为每个唯一correlation id创建会话，无ASB侧的会话状态维护开销，避免了大量临时会话导致的资源浪费。
• 对比topic+订阅过滤器模式：无需为每个请求创建临时订阅、配置过滤器，也不需要维护订阅的生命周期，规避了大量短期订阅带来的ASB性能损耗。

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