上个月半夜被线上告警叫醒,理由是数据同步队列积压过十万,消费者日志里反复出现 ClassNotFoundException。查到最后,问题不是 broker 挂了,也不是消费速度慢,而是发送端把一个业务 DTO 交出去之后,Spring AMQP 用默认的 Java 原生序列化把对象变成了一串带类名的二进制,消费端却是另一个系统、另一个语言环境,根本无法还原。那一次之后我就意识到:大数据领域做 RabbitMQ 消息管道,消息序列化与反序列化才是真正决定链路能不能长期稳定的隐性开关。它不是“调个 JSON 库”那么简单,而是横跨数据结构、跨语言兼容、性能、安全、失败兜底的一整套工程问题。这篇内容我会结合实际项目中踩过的坑来拆解,适合正在用 RabbitMQ 搭数据采集、实时 ETL、事件驱动管道的工程师参考。
1. 一条消息在 RabbitMQ 里被折腾几次:先理解序列化发生在哪
1.1 RabbitMQ 本身不看消息内容,只搬运字节数组
先把底层的运行逻辑说清楚:RabbitMQ 作为 broker,对消息体内容是无感的。生产者把消息发送到 exchange,经过路由规则进入 queue,broker 会把整条消息当作二进制字节流保存,最多读取 headers、properties 这些“外置标签”来完成路由、过期时间、优先级等管理操作。它不会去解析你的 body 是 JSON、Protobuf、XML,还是 Java
