Rebus写入MSMQ Extension属性时附加乱码的排查问询

这种无代码变更突然出现的异常确实棘手，结合你描述的场景，咱们可以从以下几个方向逐步定位问题：

1. 优先排查MSMQ Extension的长度限制 #

MSMQ的Extension属性有255字节的硬限制（这是MSMQ原生设计的约束），如果Rebus序列化后的头信息JSON加上相关标记的总字节数超过这个阈值，后续写入的字节就会被截断或溢出，最终表现为乱码。你可以：

• 计算正常场景下序列化后头JSON的字节数（用Encoding.UTF8.GetByteCount(jsonString)），看是否接近或超过255字节；
• 对比乱码消息的JSON部分长度，是否刚好卡在255字节左右——如果是，那基本可以确定是长度超限导致的问题。

2. 检查MSMQ底层存储与传输异常 #

有时候MSMQ所在服务器的磁盘IO异常、空间不足，或者远程队列的网络传输丢包，都可能导致Extension属性的字节数组损坏：

• 查看队列所在服务器的磁盘空间，检查系统日志里有没有IO错误记录；
• 如果使用远程队列，测试本地创建队列发布消息，看Extension是否正常，排除网络传输问题；
• 排查是否有其他进程（比如监控工具、磁盘清理程序）干扰了MSMQ的消息存储。

3. 验证压缩配置与头序列化的交互 #

你开启了EnableCompression()，Rebus会在头信息中添加rbs2-content-encoding:gzip标记，虽然你说代码没变更，但有可能依赖包被悄悄更新（比如NuGet自动更新），导致头序列化逻辑或长度变化：

• 检查发布端的NuGet包版本，对比之前正常运行时的版本，重点看Rebus.Msmq、Rebus.Serialization.Json、Newtonsoft.Json是否有更新；
• 临时关闭压缩配置（注释掉o.EnableCompression()），发布测试消息，看Extension是否还会出现乱码——如果关闭后恢复正常，那就是压缩与头序列化的组合触发了长度限制。

4. 排查头信息的动态内容变化 #

代码没变更不代表头内容完全不变，业务消息的类型名称（rbs2-msg-type）或返回地址（rbs2-return-address）可能因环境变化变长：

• 对比正常消息和乱码消息的头内容，看rbs2-msg-type的命名空间/类名是否变长，或者rbs2-return-address的服务器/队列名是否有修改；
• 这些动态内容的变长会直接增加JSON序列化后的字节数，触发MSMQ的Extension长度限制。

5. 模拟Rebus的头序列化逻辑 #

你反编译看到Rebus用Encoding.UTF8.GetBytes(JsonConvert.Serialize(...))，可以自己写个小测试复现这个过程，验证是否会出现字节溢出：

var headers = new Dictionary<string, string>
{
    {"rbs2-intent", "pub"},
    {"rbs2-msg-id", "ac543d60-e28c-49bb-8783-b5c6574a90ea"},
    {"rbs2-return-address", "myqueuename@SERVERNAME"},
    {"rbs2-senttime", "2018-04-26T00:20:48.0453055-03:00"},
    {"rbs2-corr-id", "ac543d60-e28c-49bb-8783-b5c6574a90ea"},
    {"rbs2-corr-seq", "0"},
    {"rbs2-msg-type", "ClassNamespace.BusinessClassName, ClassNamespace"},
    {"rbs2-content-type", "application/json;charset=utf-8"},
    {"rbs2-content-encoding", "gzip"}
};

var json = JsonConvert.SerializeObject(headers);
var bytes = Encoding.UTF8.GetBytes(json);
Console.WriteLine($"JSON字符串长度：{json.Length}，转换后字节数：{bytes.Length}");
Console.WriteLine($"是否超过MSMQ Extension限制：{bytes.Length > 255}");

运行这个测试，就能直观看到序列化后的字节数是否触发了255字节的限制。

6. 检查MSMQ消息属性的异常修改 #

排查是否有其他程序或工具意外修改了消息的Extension属性：

• 用MSMQ Explorer查看乱码消息的原始Extension字节，对比正常消息的字节数组，看乱码部分是否是额外的垃圾字节；
• 检查服务器上是否有消息监控、清理类的第三方工具，是否会对MSMQ消息属性进行修改。

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