六月的某个深夜，生产环境的报警声响了。队列积压、内存告急，而罪魁祸首竟是我亲手引入的那套消息中间件——每条 ReportMessage 序列化后接近 2.5MB 的体量，将 Broker 的吞吐按在地上反复摩擦。那晚之后我下定决心：与其继续与外部中间件缠斗，不如自建一座轻量的本地邮局。

于是有了 ReportQueueService：一条 LinkedBlockingQueue 作信箱，一个 ThreadPoolExecutor 当邮差。入队只做引用传递，出队即投递，中间不再经过任何网络往返。核心思想极朴素——队列与线程池分离，生产者只管投信，消费者只问回报，二者通过队列解耦，互不拖欠。

内存账本同样值得细算。2.5MB 的消息乘以上千条积压，堆内便是天文数字。于是我把目光投向压缩：GZIP 以 CPU 换空间，胜率稳定在 85% 上下；Snappy 则快得惊人，解压近乎零开销，代价是压缩比略逊三分。最终我选择按消息类型分流：大报文走 Snappy，普通文本走 GZIP——这已经是后话。

任何架构决策都不是单选题。放弃 RabbitMQ 并非因为它不好，而是因为它太重：重依赖、重运维、重心智。在一个消息量可控、单机即可承载的场景里，一个精心设计的本地队列，往往比一套完整的 MQ 体系更配得上"恰当"二字。全文六千字，尽在 技术版 首栏。