Azure Service Bus会话队列适配多用户及非代理连接技术咨询

Hey there! Let's break down your questions about Azure Service Bus Session-enabled queues step by step:

Absolutely! This is exactly what session-enabled queues are built for, and it fits your use case perfectly:

• Each user’s unique Session GUID acts as their exclusive "channel" in the queue. When you set the SessionId on outgoing messages, Service Bus guarantees only the receiver that accepted that specific session can pick up those messages—so users will only get their own responses.
• Thousands of users can receive messages in parallel. Each session receiver operates independently; Service Bus handles routing messages to the correct session, so there’s no blocking between different user sessions.
• The Standard tier supports scaling to handle thousands of concurrent sessions, as long as you manage connections efficiently (we’ll cover that in the next section).

First, a quick clarification: Non-brokered (direct) connections bypass the Service Bus broker’s connection pooling for operations, which helps you avoid hitting the 1000 brokered connection limit. This is critical for scenarios with many concurrent session receivers.

Sending Side Code Check #

Your current sender code uses the legacy Microsoft.ServiceBus.Messaging SDK. Let’s address your questions:

1. Is your current sender using non-brokered connections?
   No, the legacy QueueClient uses brokered connections by default.
2. Correct non-brokered sending code (using the modern Azure.Messaging.ServiceBus SDK):
   The modern SDK natively supports direct mode via ServiceBusClientOptions. Here’s how to implement it:

// Use the modern Azure.Messaging.ServiceBus SDK
var clientOptions = new ServiceBusClientOptions
{
    TransportType = ServiceBusTransportType.AmqpWebSockets, // Or AmqpTcp if preferred
    ConnectionMode = ServiceBusConnectionMode.Direct // Enables non-brokered connections
};

await using var client = new ServiceBusClient("Endpoint=sb://XXXXXX", clientOptions);
await using var sender = client.CreateSender("ResponseQueue");

var message = new ServiceBusMessage
{
    SessionId = "XYZ",
    MessageId = "XYZ"
};

await sender.SendMessageAsync(message);

Note: The legacy SDK doesn’t support direct mode natively, so migrating to the modern SDK is strongly recommended for this functionality.

Receiving Side Code Check #

Your receiver code also uses the legacy SDK. Let’s go through your questions:

1. Is your current receiver using non-brokered connections?
   No, the legacy AcceptMessageSession method uses brokered connections.
2. Correct non-brokered session receiving code (modern SDK):

var clientOptions = new ServiceBusClientOptions
{
    TransportType = ServiceBusTransportType.AmqpWebSockets,
    ConnectionMode = ServiceBusConnectionMode.Direct
};

await using var client = new ServiceBusClient("Endpoint=sb://XXXXXX", clientOptions);
// Accept the specific session for the user
await using var receiver = client.CreateSessionReceiver("ResponseQueue", "XYZ");

// Wait up to 20 seconds for a message
var receivedMessage = await receiver.ReceiveMessageAsync(TimeSpan.FromSeconds(20));
if (receivedMessage != null)
{
    Console.WriteLine($"{receivedMessage.MessageId} {receivedMessage.SessionId}");
    await receiver.CompleteMessageAsync(receivedMessage);
}

3. Do you need to set TimeSpan(0,0,0) for non-brokered connections?
   No, that’s not required. The receive timeout controls how long the receiver waits for a message before returning null—non-brokered connections are enabled by the ConnectionMode.Direct setting, not the timeout value.

Key Tips #

• The legacy Microsoft.ServiceBus.Messaging SDK is deprecated, so switching to Azure.Messaging.ServiceBus gives you better performance, newer features, and official support for direct connections.
• Direct connections reduce brokered connection count by reusing a single underlying connection for multiple operations, which helps you stay under the 1000 limit even with thousands of concurrent users.

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