使用Azure ServiceBus的MassTransit Consumer未接收消息问题排查

嘿，我之前也碰到过类似的情况——消息能顺利发出去，但消费者就是没动静，咱们一步步来揪出问题所在：

1. 先核对队列名称的一致性 #

Azure ServiceBus的队列名称是区分大小写的！你发送消息的目标队列名，和接收端点配置的队列名必须完全一模一样，哪怕只是大小写不同，都会导致收不到消息。比如发消息用的是"user-signup-queue"，接收端写成"User-Signup-Queue"，那肯定白搭。

2. 确认消费者注册是否到位 #

你得确保在配置接收端点时，真的把对应的消费者注册进去了，而且消费者类必须实现IConsumer<T>接口（T就是你发送的消息类型）。
给你个正确的注册示例：

cfg.ReceiveEndpoint("your-target-queue", e =>
{
    e.Consumer<YourMessageConsumer>();
});

另外，如果消费者有依赖注入的需求，得保证你的DI容器能正确解析它，不然MassTransit创建消费者实例会失败，这种情况日志里一般会有报错提示。

3. 检查Azure ServiceBus的权限配置 #

你的ServiceBus连接字符串对应的账号，得有**Listen（监听）**权限！如果只有Send（发送）权限，消费者连队列都连不上，更别说收消息了。
可以去Azure Portal里的ServiceBus命名空间，找到Access Policies，看看对应的权限是不是包含Listen。

4. 开启MassTransit日志找线索 #

开启MassTransit的日志（比如用Serilog、NLog）能帮你找到很多关键信息：比如接收端点有没有成功启动、有没有尝试连接队列、有没有消息被拒绝或者丢进死信队列。
举个配置Serilog的例子：

var bus = Bus.Factory.CreateUsingAzureServiceBus(cfg =>
{
    cfg.UseSerilog();
    // 其他配置项...
});

如果日志里出现Error receiving message或者Consumer failed这类字样，那就能直接定位到具体问题了。

5. 确保消息类型和序列化完全匹配 #

发送端和接收端的消息类型必须完全一致，包括命名空间！比如你发送的是MyProject.Messages.OrderSubmitted，接收端的消息类型得是同名同命名空间的，不然MassTransit的默认Json序列化器会识别不出这条消息，直接跳过。
要是你自定义了序列化器（比如Xml），两边的配置也得保持一致。

6. 看看死信队列里有没有“漏网之鱼” #

如果消费者处理消息时连续抛出异常，超过重试次数后，消息会被移到死信队列（Dead-Letter Queue）里。你可以去Azure Portal的对应队列，查看Dead-Letter Subqueue，要是里面有消息，说明消费者的处理逻辑有问题，得检查代码里的异常情况。

7. 确认Bus是否保持运行状态 #

在你的MainAsync方法里，一定要启动Bus后保持程序运行，不然Bus刚启动就跟着程序一起关闭了，消费者根本没机会接收消息。
正确的写法应该是这样：

await bus.StartAsync();
try
{
    // 发送消息的逻辑...
    Console.WriteLine("按任意键退出程序");
    Console.ReadKey(); // 让程序保持运行
}
finally
{
    await bus.StopAsync();
}

要是你的程序启动后直接退出，那Bus也会立刻停止，自然收不到任何消息。

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