RabbitMQ客户端线程模型哪些变更催生了Spring AMQP的DMLC？

早期版本RabbitMQ客户端无法支持多并发消息投递，因此需要原有的架构；新版客户端调整了线程模型，已支持并发能力，因此可以引入DMLC，监听器可直接在RabbitMQ Client线程上调用，其架构实际比SMLC更简单。

结论 #

你的初步理解完全正确。

催生DMLC的RabbitMQ客户端线程模型核心变更 #

RabbitMQ Java客户端从4.0版本开始完成了线程模型重构，核心调整有两点：

• IO线程与业务回调线程完全隔离
  3.x及更早版本的客户端每个TCP连接仅绑定1个IO线程，所有Channel的handleDelivery回调、ACK请求、连接事件都串行在这个IO线程上执行。只要任意一个消费逻辑阻塞，整个连接下的所有通信都会中断，因此旧版架构中必须在Spring侧新增内部缓冲队列，让handleDelivery快速返回不阻塞IO线程，再由Spring自己的消费线程处理队列中的消息。
  4.0+版本的客户端每个TCP连接会维护独立的业务回调线程池，IO线程仅负责网络报文收发，所有业务回调事件都会提交到该线程池异步执行，IO线程不会被业务逻辑阻塞，不同Channel的回调也不会互相干扰。
• 支持同Channel下handleDelivery并发调用
  旧版客户端同一个Channel的消息投递是严格串行的，即使配置了prefetchCount>1的QoS策略，也必须等上一个handleDelivery执行完成才会投递下一条消息，无法实现单Channel的并发消费。
  4.0+版本的客户端支持同Channel并发投递，只要Channel的prefetch配额未用尽，就会持续提交handleDelivery任务到回调线程池执行，无需等待上一条消息处理完成，天然具备并发消费能力。

DMLC的架构优势 #

基于新版客户端的线程模型特性，DMLC直接去掉了SMLC中原有的内部缓冲队列和独立消费线程池，直接在客户端的回调线程上执行用户监听器逻辑，不需要额外的线程切换和消息中转，架构更简洁，资源开销也远低于SMLC。

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