RabbitHutch.CreateBus多RabbitMQ连接异常，求最优方案或方案验证

Hey there! Let's break down your issue with connecting to multiple RabbitMQ servers via EasyNetQ, and talk through better approaches plus validate your temporary solution.

The Root of the Problem #

First off, the behavior you're seeing is intentional (though confusing if you don't know about it): RabbitHutch.CreateBus() uses an internal cache by default. Once you call it with the first connection string, any subsequent calls will return that cached instance instead of creating a new one—even with a different connection string. That's why both calls end up pointing to your first RabbitMQ server.

Is Your Temporary Solution Feasible? #

From the code snippet you shared (resolving IConnectionFactory and IEasyNetQLogger from your container), your approach is totally valid. By bypassing the RabbitHutch static helper and manually constructing bus instances with unique connection factories, you're avoiding the cached singleton trap. This is a solid way to get independent connections, so if it's working for you, there's no immediate red flag here.

Better/More Structured Approaches #

If you want to refine this further, here are two clean patterns to implement multiple independent IBus instances:

1. Manual Instance Creation (No Static Helpers)

Skip RabbitHutch.CreateBus() entirely and instantiate RabbitBus directly. This gives you full control over each bus's configuration:

// Configure connection factories for each server
var factoryServer1 = new ConnectionFactory
{
    HostName = "rabbitmq-server-1",
    UserName = "admin1",
    Password = "secure-pass-1",
    VirtualHost = "/vhost1"
};

var factoryServer2 = new ConnectionFactory
{
    HostName = "rabbitmq-server-2",
    UserName = "admin2",
    Password = "secure-pass-2",
    VirtualHost = "/vhost2"
};

// Create independent bus instances
var logger = new ConsoleLogger(); // Or resolve from your container
IBus busServer1 = new RabbitBus(factoryServer1, logger);
IBus busServer2 = new RabbitBus(factoryServer2, logger);

2. Named Registrations in Dependency Injection

If you're using a DI container (like Autofac, Microsoft DI, or StructureMap), register each IBus with a unique name/key so you can resolve the correct instance when needed. Example with Autofac:

var builder = new ContainerBuilder();

// Register logger (shared or per-bus, your call)
builder.RegisterType<ConsoleLogger>().As<IEasyNetQLogger>();

// Register first bus with a name
builder.Register(ctx =>
{
    var factory = new ConnectionFactory { /* Server 1 config */ };
    return new RabbitBus(factory, ctx.Resolve<IEasyNetQLogger>());
}).Named<IBus>("RabbitMQ-Server1");

// Register second bus with a different name
builder.Register(ctx =>
{
    var factory = new ConnectionFactory { /* Server 2 config */ };
    return new RabbitBus(factory, ctx.Resolve<IEasyNetQLogger>());
}).Named<IBus>("RabbitMQ-Server2");

// Resolve when needed
var container = builder.Build();
var bus1 = container.ResolveNamed<IBus>("RabbitMQ-Server1");
var bus2 = container.ResolveNamed<IBus>("RabbitMQ-Server2");

Key Notes to Remember #

• Always dispose of each IBus instance when you're done with it (use using statements or let your DI container handle lifecycle management) to avoid connection leaks.
• Each bus instance operates independently—publishing/subscribing on one won't affect the other, which is exactly what you want for separate RabbitMQ servers.

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