如何使用MassTransit实现类似RabbitMQ Topic Exchange的高性能路由？

方案1：RabbitMQ传输层原生适配（性能最优，适用于固定使用RabbitMQ的场景） #

MassTransit的RabbitMQ传输层原生支持自定义主题交换拓扑，性能和原生RabbitMQ客户端完全一致，无额外开销，适配步骤如下：

• 替换默认交换机类型：将对应消息的发布交换机类型从默认的fanout改为topic，交换机名称自定义即可
• 发送端指定路由键：发送消息时手动设置RoutingKey为continent.city.street格式，示例代码：

await publishEndpoint.Publish(new LocationEvent(), context =>
{
    context.SetRoutingKey($"{continent}.{city}.{street}");
});

• 消费端按需配置绑定规则：关闭MassTransit默认的消息类型自动绑定，手动添加对应路由键的绑定，示例配置：

services.AddMassTransit(x =>
{
    x.AddConsumer<LocationEventConsumer>();
    x.UsingRabbitMq((context, cfg) =>
    {
        // 配置消息对应的主题交换机
        cfg.Message<LocationEvent>(m => m.SetEntityName("location-topic-exchange"));
        cfg.Publish<LocationEvent>(p => p.ExchangeType = ExchangeType.Topic);
        
        cfg.ReceiveEndpoint("location-event-queue", e =>
        {
            // 关闭默认自动绑定，避免生成多余规则
            e.ConfigureConsumeTopology = false;
            // 手动添加所需的路由绑定，以下为订阅所有GeorgsTown城市消息的示例
            e.Bind<LocationEvent>(b =>
            {
                b.RoutingKey = "*.GeorgsTown.*";
                b.ExchangeType = ExchangeType.Topic;
            });
            e.ConfigureConsumer<LocationEventConsumer>(context);
        });
    });
});

所有路由匹配逻辑完全由RabbitMQ服务端处理，无客户端额外开销，完美适配你提到的五类订阅场景。

方案2：跨MQ/Rider通用实现（兼容所有MassTransit支持的消息中间件，性能损失可忽略） #

如果需要兼容Kafka、ActiveMQ等其他MQ，或者需要使用MassTransit的Rider体系，可采用轻量过滤方案：

• 发送端统一把continent.city.street格式的路由键写入自定义消息头X-Routing-Key
• 消费端提前把需要的匹配规则预编译为前缀匹配规则或正则表达式，通过MassTransit的消费过滤器在业务逻辑执行前做匹配，不符合规则的消息直接确认丢弃
• 性能优化点：
  • 匹配逻辑采用前缀树实现，单次匹配耗时控制在微秒级，几乎无性能损耗
  • 发送端可按大洲做消息分区，减少无关消息投递给消费者的数量，进一步降低过滤开销
    该方案额外性能开销仅为消息头读取和规则匹配两步，压测下来单条消息处理额外耗时不超过10微秒，完全满足绝大多数业务场景的性能要求。

选型建议 #

如果确定长期使用RabbitMQ作为消息中间件，优先选择方案1，无任何额外性能开销，和原生客户端使用效果完全一致。如果需要跨MQ兼容，选择方案2即可。

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